# Lock files, again (but this time w/ sdists!) **URL:** \ **Category:** Standards\ **Created:** [February 22, 2024, 2:04am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593 "2024-02-22T02:04:37Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![lwasser](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lwasser/32/10253_2.png) [@lwasser](https://discuss.python.org/u/lwasser)\ **Post date:** [February 22, 2024, 6:09pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/21 "2024-02-22T18:09:44Z")
thanks @willingc watching the thread now! @ofek is hatch planning to support lock files in the future? i wasn’t aware of that feature currently but do know pdm and poetry each have a version of lock files. Note: for conda i normally use [condalock](https://github.com/conda/conda-lock) fwiw. i am not sure how or if those plugins for pdm and hatch would work into this equation. my experience is that they allow you to use your conda environments during development. my suspicion is that focusing on pip related locking vs trying to do conda as well might be cleaner because a full conda build will not happen using hatch or pdm on it’s own currently. _Disclaimer: take my thoughts with a grain of salt!_ ---
**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\ **Post date:** [February 22, 2024, 7:36pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/22 "2024-02-22T19:36:13Z")
> [@lwasser](#): > > is hatch planning to support lock files in the future? Yes, but as a wrapper around tools that will actually write that and then Hatch will appropriately map the lock files to specific environments. Most likely UV is what I’ll use. > [@radoering](#): > > I think this goal is subtly but significantly different from Poetry’s goal. Poetry does not lock for a specific environment, it creates an environment-independent lock file. It’s more like one lock file for all possible environments than a lock file for multiple specific environments. This is a good distinction and I think the trade-off that Brett has made is worth it (and is in fact what the Pixi folks were going to do). Lockers would most likely default to whatever most developers use in addition to where services are most likely to be deployed. In my mind this means 4 targets: Windows 64-bit, macOS ARM, Linux 64-bit & ARM. Users can set specific targets to override the defaults if they wish. This minimizes the work during installations which in turn limits what can go wrong in terms of bugs and security. Installation becomes iterating the entries to find which has tags that are compatible and then installing every URL. This format is also more amenable to security scanners and dependency updaters because the format is so simple. In my opinion, this is The Way ™. > [@sethmlarson](#): > > > [@brettcannon](#): > > > > An inline table of hashes of this file’s contents w/o the line containing the table (i.e. including the newline); algorithm:value pairs. Since this file is meant to be human-readable but machine-writable this makes sure people don’t accidentally try to edit the file by hand and break associations between various parts of the file. > > I love the goal of this, but I’m concerned about this value being based on serialized TOML content instead of the values encoded in the TOML. I on the other hand don’t love the goal of that and also think this particular implementation would make it hard to contribute. I think there should be no hashes of the file contents nor timestamps. If you include either of these then multiple engineers contributing to the same code base will encounter merge conflicts frequently. I believe there was an open issue with Poetry about that that I think is still not fixed. edit: found the Poetry issue [Make the lock file more merge-friendly · Issue #496 · python-poetry/poetry · GitHub](https://github.com/python-poetry/poetry/issues/496) > as long as there is a line `content-hash` we will never be able to conveniently use dependabot. When dependabot runs, it creates 1 branch and merge request per update, w/ the idea that you let your CI run, and then auto-merge. > However, because of `content-hash` , with poetry, every single one of these branches has a merge conflict and must be manually dealt with, increasing the human time from a few seconds to ~10-minutes per, and, causing another run of the CI to be required. edit 2: a cursory glance at other lock files appears to show no precedence for storing such data. I looked at `Cargo.lock`, `yarn.lock`, `go.mod`/`go.sum`, and `Gemfile.lock` Other than this critique, I love the proposal and thank you very much for doing this Brett 😄 ---
**Author:** ![BrenBarn](https://avatars.discourse-cdn.com/v4/letter/b/74df32/32.png) [@BrenBarn](https://discuss.python.org/u/BrenBarn)\ **Post date:** [February 22, 2024, 7:50pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/23 "2024-02-22T19:50:29Z")
Good to see some ideas on this matter! I will have to think about it more but have a couple small points: Like @sethmlarson I’m a bit concerned about the hashes being based on the raw text of the file. It means that formatting distinctions which are semantically meaningless in TOML (such as whitespace or the use of different string delimiters) will affect the hash. Notably, the hash itself relies on one such formatting distinction: it is specified that it must be an _inline_ table. This makes me a bit nervous as it seems like an obvious pitfall for machine-writing. It looks like the POC implementation doesn’t use any TOML-writer lib but rather a textual template into which values are placed. That is okay for the POC, but in real life, if we expect this file format to be consumed and written by programs, a lot of those programs are going to want to just use a TOML-writing library. As far as I can see, `toml` (the main TOML lib I see on PyPI) doesn’t have any support for stipulating that a particular table be output as inline. It seems like the spec would be more robust if it could be described purely in terms of the semantic units of TOML (e.g., keys and values), without requiring a layer of special format handling (on input or output). My other comment is that it would be helpful to have an example lockfile that includes sdists, since including sdists was the impetus for this proposal. It looks like the current examples don’t have any. ---
**Author:** ![radoering](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/radoering/32/8399_2.png) [@radoering](https://discuss.python.org/u/radoering)\ **Post date:** [February 22, 2024, 8:19pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/24 "2024-02-22T20:19:11Z")
> [@ofek](#): > > If you include either of these then multiple engineers contributing to the same code base will encounter merge conflicts frequently. Citing from the Poetry issue, you linked since this makes sense to me: > In general it is not possible safely to merge two independent changes to a lockfile without re-solving. One can construct examples in which an upgrade to A is possible, an upgrade to B is possible, but the upgraded A and B are incompatible with one another. So if some bot has proposed both upgrades then it would be an error to merge both, even if they are compatible so far as git can tell. In that sense, being merge-friendly would actually be an anti-feature! I don’t know how other ecosystems without a hash in the lock file solve this issue or if they just accept to get invalid lock files after merging. 🤷 ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 10:59pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/25 "2024-02-22T22:59:51Z")
> [@EpicWink](#): > > Are you wedded to having `pylock` at the start of the filename? Having `*.pylock.toml` makes more sense in terms of hierarchy (more specific first), and puts the lock’s purpose at the start. It doesn’t have to be that string, but I do want a prefix so any lock files sort together. I don’t want to `ls` a directory and have to hunt for all of the lock files. > [@EpicWink](#): > > Also, this change better supports an idea of a default lock-file `pylock.toml`, where the purpose isn’t named. I think “default” is a fine name to use. 😉 > [@EpicWink](#): > > Are installers free to pull from an index not specified in this list? I purposely didn’t prescribe how tools were to interpret the data. I wouldn’t expect lockers to suddenly use different indexes as that would cause drifts between lock entries. > [@EpicWink](#): > > Does that allow PEP 517 `prepare_metadata_for_build_wheel`? Implicitly, yes. Just consider the listed sources as examples, not definitive. > [@EpicWink](#): > > Any support for non-Git VCS? [Version specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/#file-urls) support arbitrary VCS. You can consider the Git section as an example if you want, but I thought that Git made sense to start with. Plus the format is flexible enough that adding more type’s later wouldn’t be hard standards-wise. > [@pf\_moore](#): > > One point I was unsure about was how a lockfile consumer picks which lock entry to use - specifically around the tags. Installer tool’s choice. I’m assuming the installer will decide which lock entry makes the most sense for the environment. Since each lock entry is meant to represent the same outcome, albeit in a environment-specific way, it shouldn’t lead a semantically different outcome if there’s more than one option. > [@pf\_moore](#): > > Checking the mousebender implementation I see you have “strict” and “compatible” matching defined. I think that in the actual PEP, it would be useful to document those two matching modes, even if you prefer them only to be examples, and explain when you’d expect each of them to be appropriate. 👍 > [@pf\_moore](#): > > The installation report doesn’t record the wheel tags pip used, so I can’t populate the `lock.tags` array. You could fake it with the wheel tags from the wheel files themselves. > [@pf\_moore](#): > > The PEP should probably include a rationale for why it’s important to have separate `wheel` and `sdist` tables 👍 And it’s for flexibility for future additions of types by making all distinct types, well, distinct. 😁 > [@pf\_moore](#): > > Pip doesn’t record build environment details, so I have to omit `lock.sdist.build-requires`. I assume this would mean “installers should use their default mechanism for creating a build environment, and so can’t guarantee reproducibility”, and I think that’s fine. Is that your expectation? Sure. I wasn’t expecting pip to throw that info out, so I had not explicitly considered it. But as I said earlier in this post, I’m trying to not be too prescriptive for at least installers. > [@pf\_moore](#): > > I also note that the `lock.git` type doesn’t include a `build-requires` section. I assume it should, as a git repository contains source. Yep, that’s an oversight on my part. > [@pf\_moore](#): > > Also, while I see the practical reasons for having a specific “git” lock entry file type, I can see people pushing back on git getting “special treatment”. Maybe the PEP should describe this in terms of general support for VCS file types, with git being the only one defined in this iteration of the spec, but additional VCS types can be added in future spec versions as needed. 👍 I can also leave `lock.git` out of the PEP if that’s easier. It just seemed the only other thing beyond wheels and sdists that people might ask for in a 1.0 spec. > [@cemici](#): > > Do I understand correctly that these lockfiles contain one `[lock]` entry for every possible (distinct) environment? > > eg an entire description for “python 3.10 and x86-64”, another entire description for “python 3.9 and pypy and not extras=foo”, and so on? Yes except for the extras part; the top-level `dependencies` keeps the requirements consistent. > [@cemici](#): > > for something like poetry, that would seem to require it to examine all of the markers that it encountered during locking, enumerate all of the exponentially many possible combinations, optionally merge where possible, and then write complete solutions for all of those possible combinations? If they want to keep their environment-agnostic lock file approach, probably. > [@cemici](#): > > Edit: a package with n extras - even if it supported exactly one environment - would have 2\*\*n entries? I don’t see why the number of extras matters unless every extra is used somehow? And each extra are like a completely different projects for resolving, so it’s no different than requiring yet another distribution. > [@jeanas](#): > > > [@brettcannon](#): > > > > An inline table of hashes of this file’s contents w/o the line containing the table (i.e. including the newline); algorithm:value pairs. > > What algorithms are allowed? Any. I don’t think any of the packaging standards that involve hashes mandate anything, e.g. [Simple repository API - Python Packaging User Guide](https://packaging.python.org/en/latest/specifications/simple-repository-api/#project-detail) . If you wanted to be specific here I would say that’s a separate PEP to update all standards. (and as I said in my opening, I am not trying to revolutionize anything here). > [@pf\_moore](#): > > > [@brettcannon](#): > > > > ## `lock.wheel.dependencies` > > > > A list of normalized distribution names which this distribution depends on. Viewing the overall lock entry as the entire worldview of distributions available, each entry can be just the distribution name (a perk of Python not allowing multiple distribution versions simultaneously). This allows for introspection as to why a distribution is included in the lock entry (i.e. calculate the dependency graph between distributions). Details like extras and markers are not necessary as the resolver has already handled them. > > I’m not sure pip can determine this accurately Huh, I wasn’t expecting that as I seem to have it from my resolver. > [@pf\_moore](#): > > If it’s not possible to calculate the dependencies accurately, what’s the best thing for lockfile producers to do? I honestly don’t know because I wasn’t expecting to be told that info was in no way available. > [@pf\_moore](#): > > I don’t really know what the intended use is for this field, and therefore whether partially accurate information is better or worse than no information at all. The use case is to know _why_ a distribution file is there. I thought recording the parent → child relationship would be the easiest, but would inverting the direction be easier? Basically I want to be able to generate a dependency graph of what ends up in a lock entry so I can see who pulled in a certain distribution. > [@radoering](#): > > I think this goal is subtly but significantly different from Poetry’s goal. Correct. Poetry seems to want to generate a lock file that shrinks the world down to what’s possibly needed, but still do resolving at install time. That is different than what I’m proposing. > [@radoering](#): > > Maybe, I’m missing something but so far, I don’t think that Poetry could adopt this format without giving up its key features. I’m not saying that Poetry’s lock file format is better (it definitively has flaws), it just has a slightly different goal. Fair enough. I would not be offended if you said you would propose Poetry’s lock file for standardization if my idea gets rejected. > [@sethmlarson](#): > > > [@brettcannon](#): > > > > An inline table of hashes of this file’s contents w/o the line containing the table (i.e. including the newline); algorithm:value pairs. Since this file is meant to be human-readable but machine-writable this makes sure people don’t accidentally try to edit the file by hand and break associations between various parts of the file. > > I love the goal of this, but I’m concerned about this value being based on serialized TOML content instead of the values encoded in the TOML. I’m imagining interactions between TOML auto-formatters and lockfile tooling causing frustration for users. To avoid this we could base this hash value on the values themselves instead of the serialized TOML? A simple example to illustrate my suggestion being: `hash(json.dumps(..., sort_keys=True))` It’s a reasonable idea to shift that way. That’s [what `conda-lock` does](https://github.com/conda/conda-lock/blob/93135c17dc3b778db5321d51a7fb5958818ec597/example/zlib/conda-lock.yml#L19-L22). It’s obviously a bit more involved thanks to dicts not being hashable, but I would assume we would convert them to tuples of two-item tuples which are sorted (and lists to tuples). > [@sethmlarson](#): > > > [@brettcannon](#): > > > > Having the name as a distinct key also has the benefit that its easier to read than from a wheel file name. > > Should we include the wheel/sdist files’ `version` for similar reasons? 🤷 I honestly only added `lock.wheel.name` and `lock.sdist.name` because of direct references. > [@sethmlarson](#): > > Love the definition for `lock.sdist.build-requires`, do you have an example using this feature? Nope. 😅 Adding sdists to the resolver I had to write for wheel files would not be a small undertaking. > [@sethmlarson](#): > > For hashes it’s common to require at least one algorithm always be present for interoperability, I recommend `sha256`? See my comment earlier on hashes and packaging standards. > [@pf\_moore](#): > > These seem reasonable options, although I feel that strict matches could be fragile, especially given that we now have packaging utilities written in both Python and Rust, and we can’t assume that the exact values produced by the `packaging` library will be used by all tools I expect the strict match is more for when you write a lock file to cache what you installed for faster installs in the future. > [@ofek](#): > > I on the other hand don’t love the goal of that and also think this particular implementation would make it hard to contribute. I think there should be no hashes of the file contents nor timestamps. If you include either of these then multiple engineers contributing to the same code base will encounter merge conflicts frequently. I believe there was an open issue with Poetry about that that I think is still not fixed. > > edit: found the Poetry issue [Make the lock file more merge-friendly · Issue #496 · python-poetry/poetry · GitHub](https://github.com/python-poetry/poetry/issues/496) Fair enough. A hash could also be managed outside of the file itself. As I said earlier I got it from `conda-lock`, but I am not strongly attached to it being required or even supported. > [@BrenBarn](#): > > My other comment is that it would be helpful to have an example lockfile that includes sdists, since including sdists was the impetus for this proposal. It looks like the current examples don’t have any. That’s a massive undertaking, so people may need to use their imaginations for that one. I already had to write my own resolver which means I have partially implemented an installer already. Source distribution support would easily double that workload for me. ---
**Author:** ![cemici](https://avatars.discourse-cdn.com/v4/letter/c/91b2a8/32.png) [@cemici](https://discuss.python.org/u/cemici)\ **Post date:** [February 22, 2024, 11:19pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/26 "2024-02-22T23:19:52Z")
> [@brettcannon](#): > > I don’t see why the number of extras matters unless every extra is used somehow? If I have an an application with n optional extras, and I want to build a lockfile associated with that package, then it seems like a solution for each of the 2\*\*n possible combinations of extras would need to be written separately in that lockfile. Perhaps I have just not understood what the use case for these lockfiles is. Is that not a thing that someone would want to do with them? ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:27pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/27 "2024-02-22T23:27:20Z")
Proposal updates: - Made `file-hashes` hash the contents the file instead of the raw bytes (I have not updated my proof-of-concept as some are suggesting to drop `file-hashes` entirely) - `[[lock.git.build-requires]]` was added (it was an oversight to leave it out) ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:32pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/28 "2024-02-22T23:32:18Z")
> [@cemici](#): > > If I have an an application with n optional extras, and I want to build a lockfile associated with that package, then it seems like a solution for each of the 2\*\*n possible combinations of extras would need to be written separately in that lockfile. Only if they are used or you are trying to emulate Poetry. Othewise you would have to do this today anyway w/ e.g. requirements files, so I don’t see how what I’m proposing is any different in this regard. > [@cemici](#): > > Perhaps I have just not understood what the use case for these lockfiles is. Is that not a thing that someone would want to do with them? Depends on what you’re trying to accomplish. Lock files are typically used to record/cache what was installed for faster future installs or making sure everyone is using the same thing. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [February 22, 2024, 11:32pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/29 "2024-02-22T23:32:24Z")
> [@brettcannon](#): > > > [@pf\_moore](#): > > > > The installation report doesn’t record the wheel tags pip used, so I can’t populate the `lock.tags` array. > > You could fake it with the wheel tags from the wheel files themselves. I guess so. But that makes the tags field very unpredictable, and makes strict mode matching essentially impossible for installers. I’m fine with the “keep it flexible” principle, but I think we have to consider the realities here as well, and that might mean being a little more specific than you’d ideally like. Let’s come back to this later, though - I’m sure people will start weighing in with use cases, which will probably make it easier to decide what works best. > [@brettcannon](#): > > > [@pf\_moore](#): > > > > Pip doesn’t record build environment details, so I have to omit `lock.sdist.build-requires`. I assume this would mean “installers should use their default mechanism for creating a build environment, and so can’t guarantee reproducibility”, and I think that’s fine. Is that your expectation? > > Sure. I wasn’t expecting pip to throw that info out, so I had not explicitly considered it. But as I said earlier in this post, I’m trying to not be too prescriptive for at least installers. It does mean that you need to mark `build-requires` as optional. You said everything is required unless stated otherwise, but I think the only thing you marked as optional is `requires-python`. > [@brettcannon](#): > > > [@pf\_moore](#): > > > > I’m not sure pip can determine this accurately > > Huh, I wasn’t expecting that as I seem to have it from my resolver. I’ll look into this a bit more, but it’s definitely the case that it isn’t available from the current pip installation report. It might be possible to determine it from the resolvelib output - that’s the part I haven’t checked yet. It seems like a “nice to have” bit of information, rather than something essential for an installer, so maybe it should be marked as optional anyway? > [@brettcannon](#): > > > [@BrenBarn](#): > > > > My other comment is that it would be helpful to have an example lockfile that includes sdists, since including sdists was the impetus for this proposal. It looks like the current examples don’t have any. > > That’s a massive undertaking, so people may need to use their imaginations for that one. I already had to write my own resolver which means I have partially implemented an installer already. Source distribution support would easily double that workload for me. My pip report to lockfile code (when complete) can produce a lockfile containing sdists. But of course it’s only as correct as my interpretation of the spec, which is no better than anyone else’s 😉 ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:33pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/30 "2024-02-22T23:33:50Z")
> [@pf\_moore](#): > > It does mean that you need to mark `build-requires` as optional. You said everything is required unless stated otherwise, but I think the only thing you marked as optional is `requires-python`. Correct; I will make that change. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:34pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/31 "2024-02-22T23:34:48Z")
> [@pf\_moore](#): > > It seems like a “nice to have” bit of information, rather than something essential for an installer, so maybe it should be marked as optional anyway? I’m fine w/ that. ---
**Author:** ![cemici](https://avatars.discourse-cdn.com/v4/letter/c/91b2a8/32.png) [@cemici](https://discuss.python.org/u/cemici)\ **Post date:** [February 22, 2024, 11:38pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/32 "2024-02-22T23:38:58Z")
> [@brettcannon](#): > > you would have to do this today anyway w/ e.g. requirements files I would expect that you could normally provide a single requirements file which included entries like `foo=1.2.2 ; extra = "whatever"` - rather than having to provide two requirements files, one with and one without that entry. Perhaps I was confused by the invitation to poetry / pdm / uv folk to comment on this - it seems like that kind of package management and lockfile is not what this is for. Fair enough! ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:41pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/33 "2024-02-22T23:41:38Z")
Updates: - Made `lock.*.dependencies` optional - Made `lock.*.build-requires` optional, stating that installers can then do what they want to build the sdist, including outright refusal - Added 🔥 to the controversial keys ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:47pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/34 "2024-02-22T23:47:55Z")
> [@cemici](#): > > I would expect that you could normally provide a single requirements file which included entries like `foo=1.2.2 ; extra = "whatever"` - rather than having to provide two requirements files, one with and one without that entry. Nope, you would need to separate lock files because you effectively said the “whatever” extra was required by specifying it. > [@cemici](#): > > Perhaps I was confused by the invitation to poetry / pdm / uv folk to comment on this - it seems like that kind of package management and lockfile is not what this is for. Fair enough! They were cc’ed so they can: - Know this is being proposed - Provide feedback - Say if they would support it or not Poetry said they won’t. We haven’t heard from PDM yet, and uv has no lock file, so I can’t comment on whether they would adopt it. But Hatch seems onboard (sans Ofek not liking the timestamp and whole file hash). ---
**Author:** ![cemici](https://avatars.discourse-cdn.com/v4/letter/c/91b2a8/32.png) [@cemici](https://discuss.python.org/u/cemici)\ **Post date:** [February 22, 2024, 11:53pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/35 "2024-02-22T23:53:53Z")
Yeah, the exponential scaling in markers (including extras) is perhaps only a problem for the poetry-like general-environment case. AIUI uv intends to have poetry-like capabilities in due course, so I would guess they also will find that property unattractive. I have lost track of whether pdm lockfiles are supposed to be cross-platform or not - I think perhaps currently they are not but this is considered a bug? Anyway those projects either will or will not chip in for themselves. ---
**Author:** ![brettcannon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/brettcannon/32/34895_2.png) [@brettcannon](https://discuss.python.org/u/brettcannon)\ **Post date:** [February 22, 2024, 11:56pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/36 "2024-02-22T23:56:58Z")
> [@cemici](#): > > AIUI uv intends to have poetry-like capabilities in due course, so I would guess they also will find that property unattractive. In my discussions with them they have not suggested that, so I would rather wait for them to say what their plans are before any of us make any more guesses. ---
**Author:** ![cemici](https://avatars.discourse-cdn.com/v4/letter/c/91b2a8/32.png) [@cemici](https://discuss.python.org/u/cemici)\ **Post date:** [February 23, 2024, 12:00am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/37 "2024-02-23T00:00:42Z")
[Yes, we absolutely want to support platform-agnostic lockfiles. Very important t... | Hacker News](https://news.ycombinator.com/item?id=39392509) (and similar comments in that thread) is I think where I got this idea, but of course it will be better to hear from the source ---
**Author:** ![samypr100](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/samypr100/32/17966_2.png) [@samypr100](https://discuss.python.org/u/samypr100)\ **Post date:** [February 23, 2024, 3:39am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/38 "2024-02-23T03:39:16Z")
> [@cemici](#): > > AIUI uv intends to have poetry-like capabilities in due course, so I would guess they also will find that property unattractive. Another source to confirm this [Can we use uv for dependency management like poetry · Issue #1870 · astral-sh/uv · GitHub](https://github.com/astral-sh/uv/issues/1870#issuecomment-1960335012), but probably better to hear from directly here wrt the specific concern. ---
**Author:** ![groodt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/groodt/32/3248_2.png) [@groodt](https://discuss.python.org/u/groodt)\ **Post date:** [February 23, 2024, 3:57am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/39 "2024-02-23T03:57:57Z")
Small nitpick from me (and I know the field is controversial anyway), but if the `file-hashes` field is retained, perhaps consider a more descriptive name such as `integrity-hashes` or `integrity-checksum`. I can see an argument for retaining this field as a prompt to regenerate the lockfile. I think things like “go tidy” get run regularly enough and are fast enough due to the checksum serving infrastructure they use that perhaps it’s not needed in go.sum. I guess it’s not a deal breaker if it’s not included either. If folks do try to manually merge files in a way that results in unnecessary lockfile.entry or broken environments, the errors will eventually be fixed with regeneration of the lockfile. I expect if I had a lockfile, I would have tests in CI that regenerate the file and fail if the version in vcs differs. ---
**Author:** ![groodt](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/groodt/32/3248_2.png) [@groodt](https://discuss.python.org/u/groodt)\ **Post date:** [February 23, 2024, 4:11am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/40 "2024-02-23T04:11:13Z")
For clarification, is the primary focus on whether the format is sufficient for installers to install into a sufficient number of environments for the user? In other words, we are assuming the happy scenario where a user is installing from a lockfile into an environment they know must be supported (strict)? And then possibly an environment that they think is close enough so should work (compatible)? (I realise these semantics are at the discretion of the installer to offer) Or should we also be considering how one can produce these lockfiles as well? Because it may be tricky for a lockfile producer to produce a lockfile for the desired number of environments? Unless they limit themselves to non-Dynamic metadata? I’m guessing it’s intentional to not focus on this part so that we can agree on the format itself before worrying how on earth such a thing could be produced? [Previous page](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593.md?page=1) [Next page](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593.md?page=3)