# 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:** 11\ **Page:** 16
**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:** [March 12, 2024, 2:53pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/303 "2024-03-12T14:53:56Z")
Well, one is that there’s no actual necessity that the current project is being locked. For example, I could imagine wanting to lock the “documentation build environment” for my project, which installed things like Sphinx, etc., but did _not_ install the project itself. Hashing “the inputs” to the lock is a reasonable thing to do, but you can’t be sure what those inputs were unless you record them in the lockfile as well. ---
**Author:** ![tmk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tmk/32/10935_2.png) [@tmk](https://discuss.python.org/u/tmk)\ **Post date:** [March 12, 2024, 3:45pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/304 "2024-03-12T15:45:19Z")
Sure, if PEP 735 is accepted, then `dependency-groups` should be hashed as well. Is that what you meant? ---
**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\ **Post date:** [March 12, 2024, 3:47pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/305 "2024-03-12T15:47:52Z")
Why do lock files need _any_ interaction with the keys in `pyproject.toml`? It’s about specifying an environment, not a project. ---
**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:** [March 12, 2024, 3:52pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/306 "2024-03-12T15:52:20Z")
No. Imagine a tool (called `lock-requirements`, for example) that generated a lockfile. `lock-requirements sphinx pygments` is a perfectly valid request to create a lockfile that pins specific copies of Sphinx and Pygments, and it references _nothing_ from `pyproject.toml` (or anywhere else in the project). ---
**Author:** ![johnthagen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/johnthagen/32/3780_2.png) [@johnthagen](https://discuss.python.org/u/johnthagen)\ **Post date:** [March 12, 2024, 6:48pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/307 "2024-03-12T18:48:34Z")
Poetry uses a hash of some keys from `pyproject.toml` to allow it to validate the freshness of the lock file relative to what is in `pyproject.toml`. This allows it to catch common bugs where a user updates base requirements in `pyproject.toml` but forgets to relock the lock file. So it comes down to what responsibilities we are trying to solve with this proposal. ---
**Author:** ![tmk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tmk/32/10935_2.png) [@tmk](https://discuss.python.org/u/tmk)\ **Post date:** [March 13, 2024, 10:06am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/308 "2024-03-13T10:06:14Z")
I guess a generic solution to this would be to save a copy of the locking tool’s input in the lock file, instead of just the hash. I feel though with PEP 735, it’s not unreasonable for people to quickly write ```toml [dependency-groups] docs = ["sphinx", "furo"] ``` into `pyproject.toml` before running the locking tool. (I guess the tool would then create a separate file for that environment? `pylock.docs.toml`?) ---
**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:** [March 13, 2024, 10:56pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/309 "2024-03-13T22:56:23Z")
> [@tmk](#): > > I guess the tool would then create a separate file for that environment? `pylock.docs.toml`? That’s my personal expectation. ---
**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:** [March 13, 2024, 11:21pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/310 "2024-03-13T23:21:53Z")
FYI Frost wrote a [blog post about how lock files work in PDM](https://frostming.com/en/2024/pdm-lockfile/). ---
**Author:** ![charliermarsh](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/charliermarsh/32/10246_2.png) [@charliermarsh](https://discuss.python.org/u/charliermarsh)\ **Post date:** [March 18, 2024, 1:56am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/311 "2024-03-18T01:56:21Z")
> [@johnthagen](#): > > Poetry uses a hash of some keys from `pyproject.toml` to allow it to validate the freshness of the lock file relative to what is in `pyproject.toml`. This allows it to catch common bugs where a user updates base requirements in `pyproject.toml` but forgets to relock the lock file. For what it’s worth, I think it’s more than this. When you run `poetry install`, Poetry looks at your `pyproject.toml` to determine the root dependencies, then traverses the lockfile to figure out what to install. If you comment out all of your root dependencies and run `poetry install` without changing the lockfile, Poetry won’t install anything. In other words, Poetry _requires_ both the lockfile and the project manifest. IIUC, Cargo is similar, you need both the `Cargo.toml` and the `Cargo.lock` to do anything. ---
**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\ **Post date:** [March 18, 2024, 1:43pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/312 "2024-03-18T13:43:44Z")
> [@tmk](#): > > I guess a generic solution to this would be to save a copy of the locking tool’s input in the lock file, instead of just the hash. At the lockfile standard format specification level, the answer that makes the most sense to me is “ways to determine the ‘freshness’ of the lock file are locking tool specific, and hence appear in the `[tools]` table rather than in a standardised field (or fields)” (since there’s no one standard input format for the locking process, there can’t be a standard way to check if the resulting output is up to date). On the installer side, a generic installer will have to trust that the lockfile is up to date - checking that the lockfile is fresh before using it will necessarily be a request made of the locking tool rather than something an installer can do on its own. ---
**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:** [March 29, 2024, 2:07am UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/313 "2024-03-29T02:07:24Z")
Closing the topic so it doesn’t change as I write a draft PEP (which you shouldn’t expect any sooner than June thanks to parental leave). [Previous page](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593.md?page=15)