Repository navigation
universal-lock: clean up lock file format #3611
Description
Activity
Another piece here: we currently lose the file size (reported by the registry), which is used in downloading to facilitate prioritization (i.e., we start larger downloads earlier).
(Done in #3652.)
- added a commit that references this issue
on May 19, 2024 - added a commit that references this issue
on May 30, 2024 For testing whether conflicts happen with independent updates to the lock file, I did something like this. To start:
$ cat > pyproject.toml <<EOF [project] name = 'project' version = '0.1.0' requires-python = '>=3.12' dependencies = [ 'anyio<4.4', 'click', 'Flask<3.0.3', ] EOF $ uv lockThen I made two branches from this point: one where I changed
anyio<4.4toanyio<5and re-locked, and another where I changedFlask<3.0.3toFlask<4and re-locked. In both cases, the lock file is updated to new versions of packages. I then went back tomasterand tried to merge each of the branches, one after the other (in both orders). The result is that they both merge cleanly.I then tried this same example with Poetry. Starting with:
$ cat > pyproject.toml <<EOF [tool.poetry] name = "project" version = "0.1.0" description = "" authors = ["someone"] [tool.poetry.dependencies] python = "^3.12" anyio = "<4.4" click = "*" Flask = "<3.0.3" [build-system] requires = ["poetry-core"] build-backend = "poetry.core.masonry.api" $ poetry lockI then repeated the same process as above: creating two different branches from master, updating
anyioin one andFlaskin another and then re-locking. I then went back to master and tried to merge the anyio update branch, which worked, but then trying to merge the Flask update branch results in a merge conflict:$ git merge --no-ff ag/update-flask Auto-merging poetry.lock CONFLICT (content): Merge conflict in poetry.lock Auto-merging pyproject.toml Recorded preimage for 'poetry.lock' Automatic merge failed; fix conflicts and then commit the result. $ git diff diff --cc poetry.lock index d5a5b19,acd9943..0000000 --- a/poetry.lock +++ b/poetry.lock @@@ -217,4 -217,4 +217,8 @@@ watchdog = ["watchdog (>=2.3)" [metadata] lock-version = "2.0" python-versions = "^3.12" ++<<<<<<< HEAD +content-hash = "a84aedf401179b44c4e263992f3be48a231859fbe39edb2d8e315db13cc7f2ce" ++======= + content-hash = "5ebe45498202bf09fe0279c1096870f7f6e766ff0b09cd255f80d4aa31f723a4" ++>>>>>>> ag/update-flaskReacted by Malte Swart- added a commit that references this issue
on Jun 27, 2024 Hi, do you have any plan regarding locking of build dependencies (build-system.requires) for sdists and source trees ?
Reacted by T-256Reacted by Zanie BlueNot currently, but it would be a natural thing for us to support... It's somewhat expensive because it means we have to download the source distribution for all packages regardless of whether we can extract the metadata from a wheel alone.
And will there be a mean for the sync/install command to abort if it has to download a build dependency that is not locked?
All the issues above have been crossed off. Lets close this out for now and we can track new issues separately as they come up.
In #3314, an initial version of a universal lock file format was added. It came with a lot of TODOs in the code and some uncertainties with the data model. Before we declare the lock file ready to use by users, we should take another pass over it and smooth things out. Here is a non-exhaustive list of things:
wheeltable. The same happens for sdists I believe. I think we would ideally not havewheelorsdisttables for distributions that have apathordirectoryorgitsource. I think the rule should be that ansdistandwheeltable are only present if it's possible for more than one of them to exist. I think that only happens with registry dependencies.[distribution.dependencies]to make the file easier to scan.source = "editable+."which looks bad.source(and possibly alsoversion) from adistribution.dependencyentry when there is only one distribution with that package name.