Improve dependency resolution and markers handling

[sdispater]

Pull Request Check List

Resolves: #2187
Resolves: #2138
Resolves: #1728
Resolves: #1457
Resolves: #907
Resolves: #1772
And possibly more

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

This PR improves the overall dependency resolution logic and the way we handle environment markers during resolution.

Since managing environment markers was proving to be a headache, the best course of action was to just no longer try to dump and reconcile them in the lock file at the package level.

The environment markers of each dependencies (and transitive dependencies) are now dumped in the lock file. That way we can do a full resolution using the lock file for the current environment before installing.

This was made possible by the previous work in #2342

This introduces changes to the lock file which are backwards compatible (new versions of Poetry won't break with the older lock files) but not forward compatible (older versions of Poetry might break with this new lock file format).

Unfortunately, there is no way around it and this is the best way to fix a lot of issues with the dependency resolution aspect of Poetry.

Hopefully, the 1.1 release will be good enough for people not to want to downgrade to a previous version 😅

[flokno]

I just want to let you know that your work is much appreciated and I'm looking forward to poetry 1.1

[snejus]

I love this change, however, this is wrong

This introduces changes to the lock file which are backwards compatible (new versions of Poetry won't break with the older lock files) but not forward compatible (older versions of Poetry might break with this new lock file format).

It is a backwards-incompatible change unfortunately, at least from the user's perspective - which is the context it usually refers to. Looks like this will have to go out as 2.x and is also a bit unfortunate since people can't easily integrate the rest of improvements that are compatible. Do you reckon there's a different way which isn't based on checking out the repo and building it manually?

This probably could have been released as an extra (unless it's very much related to the rest of the changes).

[sdispater]

@snejus This is the definition of backwards compatibility, though: new versions of Poetry will understand the old lock files and it won't break any current project.

Also, the lock file, as it is, is an implementation detail and is not part of the public API so the versioning of Poetry is not impacted by the changes in the lock file format, even though we try to make these changes backwards compatible which is the case here.

[snejus]

Thanks for clarifying this! I agree with this. So, if I have 1.1.0a2 but my collaborator has 1.1.0a1, can we continue working on the same project without them requiring to upgrade? When I update the lock file, does Poetry keep the old format in place or change it to the new one?

I assumed the latter and therefore raised the question - if that's not the case please excuse me :)

[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.