-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
uv refuses to resolve deps with dynamic SCM version, missing tags and cylic dependencies A:dev -> B
, B -> A
, hinting at name shadowing
#8148
Comments
Here are more verbose logs: https://github.com/mkdocstrings/griffe/actions/runs/11307459194/job/31449208076. |
Ah, maybe it's because my |
Yeah that's probably it. So, possible improvement for uv's error message: show what's the project computed version, and show that it's what is actually causing the resolution failure. Or maybe uv could ignore the fact that the built project has a version incompatible with what a dependency is requiring? Maybe a "responsible adult" move, maybe a footgun. As for the immediate solution, I guess I'll just always fetch tags in CI! Feel free to close 🙂 |
Wait, no, I actually fetch all tags in this job 😩 Lemme try again with different options on the checkout action. |
OK so my previous technique for fetching tags was probably not working well: - name: Fetch all tags
run: git fetch --depth=1 --tags I replaced it with: - name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0
fetch-tags: true ...and now it works 🥵 |
Thank you for following up 🙏 Is there a bug in the error message hint then? Or is this resolved? |
I wouldn't call it a bug, I would say it is confusing. Seeing this error message didn't help me understand what was going on, and the "name shadowing" hint is... incorrect? As mentioned above, I'm not shadowing a dependency name, the project and the dependency are the same project. So my recommendation, if this is actually what's happening, and if it's possible, is to update the error message by showing that the computed project A version (current project, built for a non-editable install), and the version of project A required by a (dev-)dependency are not compatible. Bonus point if uv detects that the
(well, something like this) My alternative suggestion above is allow incompatibility between the current project version and the version required by dependencies, and install the current project anyway, always, maybe just showing a warning:
Let me know if anything is unclear |
One argument in favor of allowing the current project version to be imcompatible with the version required by a dependency is that when forking a repository on GitHub, tags are not copied over. Then when triggering CI on your fork, the checkout action can't fetch tags since they don't exist, and uv fails to resolve. To fix this, authors of the fork have to explicitly fetch tags from upstream and push them back into their fork. Or that's an argument in favor of me dropping dynamic versioning and using a static, auto-bumped version for each release 😄 |
A:dev -> B
, B -> A
, hinting at name shadowingA:dev -> B
, B -> A
, hinting at name shadowing
I have updated the title, and built a reproduction. git clone git@github.com:pawamoy/repro-uv-8148-a
cd repro-uv-8148-a
uv sync # works fine
# Now we clone a fork of the same project,
# meaning we don't have the Git tags.
cd ..
git clone git@github.com:pawamoy-forks/repro-uv-8148-a repro-uv-8148-a-fork
cd repro-uv-8148-a-fork
uv sync # fails with the following output % uv sync
Using CPython 3.12.7 interpreter at: /home/pawamoy/.basher-packages/pyenv/pyenv/versions/3.12.7/bin/python
Creating virtual environment at: .venv
× No solution found when resolving dependencies:
╰─▶ Because only repro-uv-8148-b==0.1.1 is available and repro-uv-8148-b==0.1.1 depends on your project, we can conclude that all versions of repro-uv-8148-b depend on
your project.
And because repro-uv-8148-a:dev depends on repro-uv-8148-b and your project depends on repro-uv-8148-a:dev, we can conclude that your project's requirements are
unsatisfiable.
hint: The package `repro-uv-8148-b` depends on the package `repro-uv-8148-a` but the name is shadowed by your project. Consider changing the name of the project. I'd love to have a flag (CLI flag or config option in pyproject.toml or both) to tell uv that I'm not shadowing the dependency's name, that they're the same thing, and that I want to install the current project anyway, even if its built version isn't compatible with what the dependency requires. |
I thought about and tried using dependency overrides, which solves the resolution issue, but makes uv actually install the current project as a dependency instead of as an editable install. [tool.uv]
override-dependencies = ["mkdocstrings>=0"] I also tried configuring a source for [tool.uv.sources]
mkdocstrings = { workspace = true } ...and: [tool.uv.sources]
mkdocstrings = { path = ".", editable = true } ...but it is still not installed as editable. The dependency override seems to take precedence. |
Haha, I then tried this: [tool.uv]
override-dependencies = ["mkdocstrings @ ."] ...which failed with this message:
And then tried this: [tool.uv]
override-dependencies = ["mkdocstrings @ ${PWD}"] ...which worked 🎉 but looks so weird haha Overriding self with self 🫠 It makes sense in a way: "yes, use self project as is, don't pay attention to what others say about it". So, in the end, I think you can close! A paragraph in the docs could be nice (but it feels super niche too, so maybe not worth it). |
One issue with using |
Hmm, uv already supports this env var, although it's undocumented (or at least searching for it in the docs doesn't yield anything). What I'm not sure to understand is that it seems to be equivalent to PWD: if I enter a subdirectory and run |
I think we need to support that to build projects that use Hatch (but otherwise it's not really a first-class thing). |
I guess what you're looking for here is for us to respect sources on top of overrides? I'm sort of surprised we don't, honestly. |
If you think there's some room for improvement in the way uv handles overrides and sources, I'm happy to help any way I can! Just to be clear, I'm only using overrides now, not declaring any source. |
I prefer declaring this: [tool.uv]
override-dependencies = ["mkdocstrings @ ${PROJECT_ROOT}"] Than this: [tool.uv]
override-dependencies = ["mkdocstrings>=0"]
[tool.uv.sources]
mkdocstrings = { workspace = true }
# or mkdocstrings = { path = "${PROJECT_ROOT}", editable = true } ...because even if the result is the same, it feels like the latter will completely disregard any constraints incompatibilities in dependencies regarding (I hope it's fine that I commented so much on this issue! Not trying to get your attention, just documenting my journey and thought process 😄) |
Hmm wait, need to confirm. Yeah so it's worse than that, the override actually prevents the project to be installed in editable mode. Damn I'm going in circles 🤣 This might be an argument favor in of the second option above, if its changed to support editable installs again, thanks to sources. UPDATE: I've updated https://github.com/pawamoy/repro-uv-8148-a to document all this in the readme. |
In the end you guessed right @zanieb: I think the correct thing to declare on my end is this: [tool.uv]
override-dependencies = ["mkdocstrings @ ${PROJECT_ROOT}"]
[tool.uv.sources]
mkdocstrings = { path = "${PROJECT_ROOT}", editable = true } (or some simplification of this, if such a simplification is already possible, or deemed useful enough to become supported in the future) uv then just needs to respect the sources on top of overrides, like you said 🙂 |
@charliermarsh, wdyt about changing this interaction of sources and overrides? |
Yeah that makes sense... It seems like sources should apply to overrides and constraints too? |
## Summary We still only respect overrides and constraints in the workspace root -- which we may want to change -- but overrides and constraints are now correctly lowered. Closes #8148.
Thank you so much! I played with main branch, here are my findings. This works: [tool.uv]
override-dependencies = ["repro-uv-8148-a"]
[tool.uv.sources]
repro-uv-8148-a = { workspace = true } (and by "this works" I mean no conflicts, But none of the following work (which is fine, just had to find the right combination with trial and error):
Thank you again! |
In the latter two cases, did you have |
No I didn't, because I didn't think it made sense, since [tool.uv.workspace]
members = ["${PROJECT_ROOT}"] # or members = ["."] ...I still get the "Package is not included as workspace package in |
… resolving deps in forks/CI Issue-uv#8148: astral-sh/uv#8148
Oh thanks. What do I need to do exactly to reproduce the latter two cases? Clone |
git clone https://github.com/pawamoy-forks/repro-uv-8148-a
cd repro-uv-8148-a Apply this patch: diff --git a/pyproject.toml b/pyproject.toml
index 40277fc..769d33c 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -20,6 +20,15 @@ version = {source = "scm"}
package-dir = "src"
[tool.uv]
-dev-dependencies = [
+override-dependencies = ["repro-uv-8148-a"]
+
+[tool.uv.sources]
+repro-uv-8148-a = { path = "${PROJECT_ROOT}", editable = true }
+
+[tool.uv.workspace]
+members = ["${PROJECT_ROOT}"]
+
+[dependency-groups]
+dev = [
"repro-uv-8148-b>=0.1",
] Run |
Thank you! |
So in this case, you're providing a source for the package itself? (Maybe I missed all the context above.) |
Haha yes you probably missed the important bits in the wall of comments I posted above 😄 So, let say I'm working on project The issue here is that my version is dynamic, and based on Git tags (pdm-backend deals with this). When there are no tags (fork, CI), pdm-backend computes version 0.1.devblabla, which is incompatible with what Hence why I'm trying to tell uv to ignore constraints on the current project. The only current way to do this, is to use the configuration above: [project]
name = "a"
dynamic = ["version"] # dynamic version...
[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"
[tool.pdm]
version = {source = "scm"} # ...based on Git tags, through pdm-backend
[tool.uv]
override-dependencies = ["a"] # tell uv to ignore constraints...
[tool.uv.sources]
a = { workspace = true } # ...while still installing from current folder, in editable mode
[dependency-groups]
dev = [
"b>=0.1", # b depend on a>=1.0
]
Yes 😄 |
We could argue it is better solved within pdm-backend itself. It has a "fallback" mechanism, but only triggered when the folder is not a Git repository. In my case, it is a Git repository, but without tags, so it doesn't fallback. Also, the fallback version is static, so even if it worked and I fell back to v100, this could still be incompatible with what So in the end, when I'm working on |
I hit this with a setuptools backend.
From |
Thanks for chiming in @adamtheturtle! I see that uv's message has been updated, it's better than before 👍 :
But yes, ideally, it would especially show the current version (in your case By the way @adamtheturtle, note that I found a way to fallback using the latest version in the CHANGELOG.md file when tags are not found, see #10121 (comment). It might be possible to do something similar with other backends. |
Thank you @pawamoy ! |
It happens in several of my projects now. Proper issue as a follow-up of #7329.
Example:
Here uv claims that since
mkdocstrings-python-legacy
depends onmkdocstrings
, and my project is namedmkdocstrings
, it cannot resolve deps. My project ismkdocstrings
, it's not shadowing it 😅In this case,
mkdocstrings
depends onmkdocstrings-python-legacy
as an extra (optional dependency).But I get the same error when project
A
depends onB
as a development dependency.I'm not sure if the non-editable mode is the issue here, as I cannot reproduce this behavior locally.
The text was updated successfully, but these errors were encountered: