-
Notifications
You must be signed in to change notification settings - Fork 2.9k
universal-lock: clean up lock file format #3611
Copy link
Copy link
Closed
Labels
previewExperimental behaviorExperimental behavior
Description
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:
- Audit handling of hashes in the lockfile #4924
- There are some redundancies in the current format where we repeat information. For example, if we have a path dependency to a wheel, the path is encoded in the source (part of the distribution's ID) and then again in a
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. - Don't store absolute paths for path dependencies (iron out how to represent path dependencies in the universal lock file #3506)
- The actual TOML serialization format is a bit bulky right now. I think it uses table arrays a bit too much. I'd love to, for example, squash wheels down into an inline table or an array of strings.
- Consider indenting
[distribution.dependencies]to make the file easier to scan. - Improve the formatting of source, specifically paths, e.g. we currently have
source = "editable+."which looks bad. - The git source could use an audit and a potential refactor. We need to decide on how we want to encode the various git information (revision, tag, branch, sub-directory, URL).
- We should be able to drop the
source(and possibly alsoversion) from adistribution.dependencyentry when there is only one distribution with that package name. - Explore whether merge conflicts are created in basic cases. For example, if two different PRs add different dependencies and one gets merged, does the other PR wind up with conflicts that must be merged by hand?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
previewExperimental behaviorExperimental behavior