Lock files, again (but this time w/ sdists!)

[sethmlarson (Seth Michael Larson)]

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?