Allow prereleases, locals, and URLs in non-editable path requirements #2671
Conversation
charliermarsh
force-pushed
the
charlie/pre-local
branch
5 times, most recently
from
6874362
to
f3574db
Compare
|
We could in theory use the same technique to resolve these recursively, upfront, for all direct URL distributions... |
charliermarsh
force-pushed
the
charlie/pre-local
branch
2 times, most recently
from
e45f9f1
to
065fdc1
Compare
| metadata.requires_dist.iter().filter(|requirement| { | ||
| requirement.evaluate_markers(markers, &editable.extras) | ||
| }) | ||
| })) |
There was a problem hiding this comment.
Going to DRY this up in a separate PR (it's already repeated excessively on main).
charliermarsh
force-pushed
the
charlie/pre-local
branch
from
065fdc1
to
c41b934
Compare
|
A slightly different way to solve this would be to pass these paths to |
| /// | ||
| /// The lookahead resolver resolves requirements for local dependencies, so that the resolver can | ||
| /// treat them as first-party dependencies for the purpose of analyzing their specifiers. | ||
| pub struct LookaheadResolver<'a> { |
There was a problem hiding this comment.
The alternative solution would be to pass any source trees to SourceTreeResolver (so, e.g., if the user does foo @ ./bar/baz, we'd pass ./bar/baz to SourceTreeResolver alongside any pyproject.toml or setup.py files that were passed in). Then, we'd treat the requirements as part of the requirements input to the resolution.
That approach would require some refactoring of SourceTreeResolver (since it uses ExtrasSpecification, which isn't a generic concept for requirements). It would also mean that the actual Resolver wouldn't be able to distinguish between these "lookahead" requirements and actual first-party requirements, and there may not be any indication in the error messages that they came from the local directory requirement, but that might be ok. I'm open to either.
There was a problem hiding this comment.
This seems okay, but the whole SourceTree and SourceTreeResolver concept is so new that I don't have strong feelings.
I like the idea of them being included in the resolver manifest.
|
Also, I think this should be recursive… so that local deps can define local deps at any level. |
|
Thinking about it... we could actually extend this approach to enable support for transitive URL dependencies (as long as we don't allow URL dependencies to come from registry dependencies, which is fine)... The basic idea would be: recursively resolve all direct URL references, then the requirements of all direct URL references, etc. So we'd collect all possible direct URL references upfront. |
charliermarsh
force-pushed
the
charlie/pre-local
branch
from
c41b934
to
b54f827
Compare
| ) -> Result<Vec<RequestedRequirements>> { | ||
| let requirements: Vec<_> = futures::stream::iter(self.requirements.iter()) | ||
| .map(|requirement| async { self.lookahead(requirement, context, client).await }) | ||
| .buffered(50) |
There was a problem hiding this comment.
Do we want to put that value in a global constant?
|
I wonder if we should start by allowing this to be recursive for local requirements (for editables too). |
|
(But it's fine to merge as-is. That would be an extension of this work.) |
| /// | ||
| /// The lookahead resolver resolves requirements for local dependencies, so that the resolver can | ||
| /// treat them as first-party dependencies for the purpose of analyzing their specifiers. | ||
| pub struct LookaheadResolver<'a> { |
There was a problem hiding this comment.
This seems okay, but the whole SourceTree and SourceTreeResolver concept is so new that I don't have strong feelings.
I like the idea of them being included in the resolver manifest.
charliermarsh
force-pushed
the
charlie/pre-local
branch
from
b54f827
to
fd40f0b
Compare
charliermarsh
force-pushed
the
charlie/pre-local
branch
from
fd40f0b
to
d5c5a09
Compare
Summary
This PR enables the resolver to "accept" URLs, prereleases, and local version specifiers for direct dependencies of path dependencies. As a result,
uv pip install .anduv pip install -e .now behave identically, in that neither has a restriction on URL dependencies and the like.Closes #2643.
Closes #1853.