-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Project's name interferes with resolution logic #7329
Comments
I think it's correct to fail here. |
I wasn't sure either. I guess it wasn't immediately obvious why the resolution was failing, which led me to dig further. |
We could add a note about this somewhere. Is the error message helpful? |
The error got me confused at first because I did not understand why the dependency I was adding was depending on my project.
|
I see okay thanks! I think we can do better there. |
A possible solution here is that we'd add a "hint" after a resolution error (we have some infrastructure for this) if the project name shadows the name of a package available in the index. I'm not sure if we'll have checked if the package is available though. Another (perhaps easier to implement) solution is to hint if a dependency of the project depends on the project itself e.g. here |
As a side note related to
|
Oof yeah here's the whole error message. I think there's another problem here. Like we should collapse these and say "all versions of
|
Here's the derivation tree
|
) This enhances the hints generator in the resolver with some heuristic to detect and warn in case of failures due to version mismatches on a local package. Those may be the symptom of name conflict/shadowing with a transitive dependency. Closes: #7329 --------- Co-authored-by: Zanie Blue <[email protected]>
Sorry, I'm not sure to understand the issue here, which I experience too. Locally, with uv 0.4.20, I'm able to install my dependencies. Yet in CI, with the same version, 0.4.20, I'm getting this error:
The only difference between local and CI is that in CI I pass Does this hint mean that cyclic dependencies are not supported 🤔? I think it's pretty common for plugins/extensions to specify the main project as dependency (django-apps specify their accepted django versions, mkdocs plugins their accepted mkdocs versions, griffe extensions their accepted griffe versions, etc.), and then if the main project starts depending on a plugin/extension, it creates kind of a cyclic dependency (actual example: mkdocs depends on mkdocstrings to render API docs, and mkdocstrings specifies its accepted mkdocs versions), but I think it resolved fine previously. Changing project names is not possible, and removing the |
Hmmm, looks like it's working again in CI 🤷 I'll let you know if I encounter the issue again 🙂 |
Spoke too fast:
No dependency changes. Is it because the two first are on a tagged commit but not the last one O_o? |
Still cannot reproduce locally so none of this will be very helpful for you 🙇 |
Can confirm it works fine when CI is triggered by pushing a tag. Here's what I gather:
|
When attempting to
add
orsync
a dependency to a project, if the dependency depends on a package whose name matches the name in your pyproject.toml, resolution fails.Create the following pyproject.toml
Run
uv add dagster-webserver --verbose
(dagster-webserver
depends ondagster
)log.txt (too big to paste)
Changing the name in pyproject.toml makes it work correctly.
Running on macOS 14.6.1 (23G93), with uv 0.4.9 (Homebrew 2024-09-10)
The text was updated successfully, but these errors were encountered: