I think you are interpreting the purpose of a lock file differently. The purpose isn’t for development but rather applications (mostly). Let me give you a concrete use case: say you have a Python application that you wish to deploy, let’s say Instagram’s website for the purpose of this conversation. Then let’s say your only dependency is Django. The following describes how to define the environment in increasingly reproducible ways:
- Depend on
- Depend on
- Same as before but now you resolve all transitive dependencies for your specific setup (Python version, OS, architecture, etc.) yielding precise version pins for the entire graph
- Same as before but now you add info so as to specifically allow for targeting of other setups (whether that is specific setups or enough info for all setups)
- Same as before but now rather than pins you store the precise URL which with the artifact is stored without support for source distributions (PEP 665)
- Same as before but now source distributions are supported which requires in most cases downloading the artifact and invoking its chosen build backend to find out the metadata which then triggers a recursive loop where it could define dependencies that also happen to resolve to source distributions
- Same as before but now also whenever a source distribution is encountered you resolve its build dependencies in the same way and store that data in a separate section
To be clear, we mean “deploy” as in install the application for a specific other user (e.g. someone else in my organization)? And in this scenario it’s my responsibility to make that happen?
Because if arbitrary others are supposed to be able to use the application, the question is how they get the lockfile, and how their installation process becomes aware of it. A wheel can’t do that, and it’s not clear to me how an sdist would do it.
In the context of something like Instagram, I would interpret “deploy” to mean something like “distribute and start the application on an arbitrary number of virtual machines”. The security of the lockfile is not a problem–the whole operation is internal to the organization doing it. But they want it to be completely reproducible.
I would say the purpose isn’t just for development but also for applications (as well as other things). For instance in the academic or data science realms there can be a desire to reproduce an environment to build on a previous analysis. And I also think that reproducing a dev environment is a valid use case. I like your list of “increasingly reproducible ways” and it lays out some of the situations that have to be considered, but I just want to point out that, at least for me, application deployment is something to be considered in addition to other use cases for lock files, not instead of them.
Yes that is a good point thank you. Lock files are for environments which applications, dev tools, etc. may use.