This is a good point. I’ve gotten used to the idea that Poetry will edit the file anyway (and I even made my own tool to modify a Poetry-based file!), but maybe we should be pushing back on that. The lock data needs to represent a solve, and in particular to find transitive dependencies (or else it’s fairly pointless); between that and hashes etc. it will pretty well always be vastly more data than the input (and nobody will sit there and compute the hashes manually). I had thought that unifying the description of a locked dependency with an input dependency made sense, and would be worth some hiccups (i.e. it makes no sense to specify a hash for something that isn’t pinned) if that data could be in the same place; but now the idea seems pointless.
(Although I still do eventually want to be able to describe individual dependencies in a more detailed way than PEP 508 - if only to include non-native stuff. Thinking really idealistically, maybe it would be neat to be able to e.g. be able to specify a Github repository, and have the installer somehow take the repository and solved version number, and locate the corresponding release file.)
I could imagine a mechanism to associate an input requirements list with a lockfile that was generated from it. But I don’t know that there would be any use for it. (Also, the solver would be tempted to update pyproject.toml to point at the lockfile it just created.)
Okay, but who else needs that information besides the devs, and how will they a) obtain and b) use it?
I don’t know how to say more about it than the rest of that paragraph. Maybe I misunderstood the threat model (it seems to be dependent on the answers to my other questions).
… Ah, one more thing:
I understood this as representing the least “strict” level of reproducibility. Should it mean more than just pinning versions? Or only that?