Skip to content

universal-lock: clean up lock file format #3611

@BurntSushi

Description

@BurntSushi

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 wheel table. The same happens for sdists I believe. I think we would ideally not have wheel or sdist tables for distributions that have a path or directory or git source. I think the rule should be that an sdist and wheel table 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 also version) from a distribution.dependency entry 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    previewExperimental behavior

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions