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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editable- and workspace-aware lookahead resolver #3733

Closed
konstin opened this issue May 22, 2024 · 1 comment
Closed

Editable- and workspace-aware lookahead resolver #3733

konstin opened this issue May 22, 2024 · 1 comment
Labels
internal A refactor or improvement that is not user-facing

Comments

@konstin
Copy link
Member

konstin commented May 22, 2024

Dependencies in uv come in two shapes: Index dependencies, with a name and a version specifier, and url dependencies, pointing to a remote file, a git repository, local file or local directory. Only url dependencies are allowed to have url dependencies, and of these only local directories are allowed to be editables.

Currently, editables are collected and built separately, and then the lookahead resolver does a DAG traversal through all url requirements and their dependencies to collect a list of the names and urls of all url requirements. This tells us when a name-version requirement elsewhere in the dependency tree is fulfilled by a url requirement and gives us the list of allowed urls.

Instead, we should stop special casing editables and make them a regular path dependency, resolved by the lookahead resolver. Editables are special because we don't store them in the cache (following the spec), so the lookahead resolver needs to return a handle to the editable with non-static metadata it had to build. In addition the lookahead resolver should consider all uv.tool metadata and perform (and cache) workspace discovery for directory dependencies (editable or not). The lookahead resolver will consider workspaces both for static and dynamic metadata, in the latter case building with PEP 517 hooks to use the 517 metadata from the build plus the resolved workspace for lowering the requirements.

@konstin konstin added the internal A refactor or improvement that is not user-facing label May 22, 2024
@konstin konstin mentioned this issue May 26, 2024
5 tasks
@charliermarsh
Copy link
Member

@konstin - I think this was solved this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal A refactor or improvement that is not user-facing
Projects
None yet
Development

No branches or pull requests

2 participants