-
Notifications
You must be signed in to change notification settings - Fork 697
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
Lock files don't mesh with dynamic package version info #7533
Comments
@hynek have you seen |
I have while searching this bug tracker, but I couldn't find a way for it to affect From the documentation (and its name 🤓) I've gathered it's mostly about how caching, not about locking? And TBH it sounds to me as if adding git as a git key, I'm actually adding cache busting. |
I think you could pass [tool.uv]
upgrade-package = ["attrs"] But there's sort of an infinite loop here, right? Since every time you commit the lockfile, it will be outdated. So you then re-lock, and commit again, etc. I don't know how to solve this holistically. We could omit versions for editables, maybe? Or even, write "dynamic" or something for the version, for packages that have dynamic versions? |
Yeah that's what I meant in my last sentence, but I'm always assuming Chesterton's Fence. :) Setting it to |
I too have this problem. I generally subscribe to the philosophy that I use a VCS for versioning, thus what is in the VSC repo shouldn't track it's own version because that's what I'm using the VCS for. Said another way, at best a version tracked within repo is imperfect for exactly the reasons described above about how you can't update a version from a commit without making another commit, i.e., a new version. I'd love to understand the rationale behind storing this version in the lock file. Can anyone elaborate on that? |
We are also facing a similar problem over at cda-tum/mqt-core#706 where we use renovate to keep the |
This problem is not only for dynamic versioning. We have a release-please workflow, which will create a PR for the next release. This will update the pyproject.toml version correctly but of course does not know about the uv.lock version. |
As I mentioned in ttps://github.com//issues/7994 I use As a workaround, I also added |
Since tox-uv just shipped lock files, I took a stab at moving attrs to a fully-locked dev environment.
Here's the experiment PR: python-attrs/attrs#1349
A problem I've run into is that packages often use dynamic packaging data that is based on git metadata (setuptools-scm, hatch-vcs, etc). As such, attrs's package version changes after every commit, which allows us to upload to test PyPI and continually verify our package. See, for example, https://test.pypi.org/project/attrs/24.2.1.dev19/
Unfortunately the current project gets locked like this:
Which means it's outdated after each commit, because every commit increments the number behind
dev
.Is there a way around this that I've missed? If not, could there be built one? 😇 AFAICT, this is currently the biggest blocker for FOSS use from uv's side. I'm also not sure what the point of that version lock is in the first place for the current, editable project? But that's a topic for another day. :)
The text was updated successfully, but these errors were encountered: