Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve dependency resolution and markers handling #2361

Merged
merged 1 commit into from Apr 29, 2020

Conversation

sdispater
Copy link
Member

@sdispater sdispater commented Apr 27, 2020

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 馃槄

@sdispater sdispater added area/solver Related to the dependency resolver area/installer Related to the dependency installer labels Apr 27, 2020
@sdispater sdispater added this to the 1.1 milestone Apr 27, 2020
@sdispater sdispater requested a review from a team Apr 27, 2020
@sdispater sdispater force-pushed the improve-dependency-resolution branch 2 times, most recently from ac5c590 to 92398ce Compare Apr 27, 2020
@sdispater sdispater force-pushed the improve-dependency-resolution branch from 92398ce to f7f7570 Compare Apr 28, 2020
abn
abn approved these changes Apr 29, 2020
@flokno
Copy link

flokno commented May 4, 2020

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

@snejus
Copy link
Contributor

snejus commented Jun 26, 2020

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
Copy link
Member Author

sdispater commented Jun 27, 2020

@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
Copy link
Contributor

snejus commented Jun 27, 2020

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 :)

adisbladis added a commit to nix-community/poetry2nix that referenced this pull request Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment