Improve intersection and union of markers

The handling of markers offers great potential for improvement. Even if marker simplifications seem intuitive to a human being, the subject is more complex than it might seem at first glance. Thus, it’s best to proceed in small steps.

This is a meta issue to keep track of these steps:

• python-poetry/poetry-core#226
• python-poetry/poetry-core#255
• python-poetry/poetry-core#282
• python-poetry/poetry-core#283
• python-poetry/poetry-core#293
• python-poetry/poetry-core#294
• python-poetry/poetry-core#297
• python-poetry/poetry-core#299
• python-poetry/poetry-core#308
• python-poetry/poetry-core#352
• python-poetry/poetry-core#380
• python-poetry/poetry-core#382
• python-poetry/poetry-core#383
• python-poetry/poetry-core#384
• python-poetry/poetry-core#388
• python-poetry/poetry-core#390
• to be continued…

Rationale

When resolving dependencies, markers play an important role. Especially, when multiple-constraints-dependencies come into play, overrides with contradicting markers should be ignored to avoid unnecessary failures in dependency resolution and speed up the resolution. See #4695 for details. In order to detect contradicting markers, intersections of markers that cannot be fulfilled have to be simplified to EmptyMarker. Analoguous, unions of markers that are always fulfilled have to be simplified to AnyMarker. At the moment, markers are not always simplified enough so that poetry is not able to detect if a marker can never be fulfilled (empty marker) or is always fulfilled (any marker).

Apart from this use case, simplifying markers seems to be mainly a cosmetic issue when looking into poetry.lock or an exported requirements.txt. (When checking if a dependency has to be installed in the current environment, it does not matter if a marker has been simplified or not.)

[dimbleby]

As you’ve seen I had a crack at the version / full_version case and it seems to have turned out fairly straightforward, albeit with room for still further improvement.

I think I’ve probably run out of ideas and enthusiasm in this area for now; not to mention that I’m already beginning to risk merge conflicts between the various MRs that are currently queued up. Over to you if you have more that you want to do - and to the maintainers to get these merged!

[radoering]

Yeah, should be quite good now.

Closing since there haven’t been much improvements/fixes anymore in the last time and I can’t come up with a good solution for merging sys_platform and platform_system.