# 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:** 1\ **Showing post:** 17
**Author:** ![sethmlarson](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sethmlarson/32/1644_2.png) [@sethmlarson](https://discuss.python.org/u/sethmlarson)\ **Post date:** [February 22, 2024, 4:39pm UTC](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593/17 "2024-02-22T16:39:10Z")
Exciting! Love the approach so far. > [@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))` > [@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? Love the definition for `lock.sdist.build-requires`, do you have an example using this feature? For hashes it’s common to require at least one algorithm always be present for interoperability, I recommend `sha256`? --- _[View the full topic](https://discuss.python.org/t/lock-files-again-but-this-time-w-sdists/46593)._