Require URL dependencies to be declared upfront#319
Merged
charliermarsh merged 1 commit intomainfrom Nov 5, 2023
Merged
Conversation
charliermarsh
force-pushed
the
charlie/strict-dependency
branch
2 times, most recently
from
869a408 to
0d043dd
Compare
charliermarsh
commented
Nov 4, 2023
| mod version; | ||
|
|
||
| /// Convert a set of requirements to a set of `PubGrub` packages and ranges. | ||
| pub(crate) fn iter_requirements<'a>( |
Member
Author
There was a problem hiding this comment.
This was all moved into the new PubGrubDependencies struct (and modified).
charliermarsh
commented
Nov 4, 2023
| { | ||
| debug!("Adding root dependency: {package} {version}"); | ||
| Self::visit_package(&package, &mut priorities, &mut in_flight, request_sink)?; | ||
| } |
Member
Author
There was a problem hiding this comment.
This isn't necessary -- we end up visiting this immediately after anyway by way of visiting the Root package.
charliermarsh
commented
Nov 4, 2023
|
|
||
| ----- stderr ----- | ||
| × No solution found when resolving dependencies: | ||
| ╰─▶ root depends on werkzeug 3.0.0 |
Member
Author
There was a problem hiding this comment.
Bad error message, sigh...
konstin
approved these changes
Nov 5, 2023
| /// To enforce this requirement, we in turn require that all possible URL dependencies are | ||
| /// defined upfront, as `requirements.txt` or `constraints.txt` or similar. Otherwise, | ||
| /// solving these graphs becomes far more complicated -- and the "right" behavior isn't | ||
| /// even clear. For example, imagine that you define a direct dependency on WerkZeug, and |
Member
There was a problem hiding this comment.
Suggested change
| /// even clear. For example, imagine that you define a direct dependency on WerkZeug, and | |
| /// even clear. For example, imagine that you define a direct dependency on Werkzeug, and |
also below
Member
Author
There was a problem hiding this comment.
FYI WerkZeug means tool in German.
charliermarsh
force-pushed
the
charlie/strict-dependency
branch
from
0d043dd to
83a2f71
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the resolver, our current model for solving URL dependencies requires that we visit the URL dependency before the registry-based dependency. This PR encodes a strict requirement that all URL dependencies be declared upfront, either as requirements or constraints.
I wrote more about how it works and why it's necessary in documentation here. I think we could relax this constraint over time, but it requires a more sophisticated model -- and for now, I just want something that's (1) correct, (2) easy for us to reason about, and (3) easy for users to reason about.
As additional motivation... allowing arbitrary URL dependencies anywhere in the tree creates some really confusing situations in which I'm not even sure what the right answers are. For example, assume you declare a direct dependency on
Werkzeug==2.0.0. You then depend on a version of Flask that depends on a version ofWerkzeugfrom some arbitrary URL. You build the source distribution at that arbitrary URL, and it turns out it does build to a declared version of 2.0.0. What should happen? (And if it resolves to a version that isn't 2.0.0, what should happen then?) I suspect different tools handle this differently, but it must lead to a lot of "silent" failures. In my testing of Poetry, it seems like Poetry just ignores the URL dependency, which seems wrong, but is also a behavior we could implement in the future.Closes #303.
Closes #284.