Fixed propagation of markers to dependencies. Fixes #3254

[apollo13]

Resolves: #3254

• Added tests for changed code.
• Updated documentation for changed code.

I ticked the documentation checkbox simply because I think there is no part in the documentation that I could adjust for this.

@abn This issue got introduced in 1188b31 which you authored; do you think you could give this PR a review?

The main logic change here is that I changed marker merging from intersect to union. The rationale for this can be followed easier if you look at the following (commented) dependency graph from the ticket:

pyinstaller 4.0 PyInstaller bundles a Python application and all its dependencies into a single package.
├── altgraph *  # PyInstaller always requires altgraph
├── macholib >=1.8 # This has a marker to only install on darwin
│   └── altgraph >=0.15  # This is a dependency also of macholib

Now the situation is as follows: Since altgraph is a non-marked dependency by PyInstaller it should always be installed, there is no way around this. An intersection of * and sys_platform='darwin' yields sys_platform='darwin' which would result altgraph to be only installed on darwin. An union ensure that it is installed always.

[apollo13]

@abn This change changes tested behavior but I'd argue that the previous behavior was in fact wrong:

• a has python_version < 3.7
• a depends on b & c which have the markers platform_system == 'Windows' and sys_platform == 'win32' respectively
• b and c both depends on d and as such their markers should trickle down, but d should get installed whenever one of the parent markers is true, not only when both are true.

On the other hand this python_version<3.7 is required for all packages, so the constraint could be rewritten as:

(platform_system == 'Windows' or sys_platform == 'win32' ) and python_version < '3.7'"

but that would probably be more work (and the current form is technically correct). For large dependency trees it might be worth to get the python version out of the nested constraints as far as possible though. But I guess this might require plenty of specialcasing.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.