In an environment, a user could be interested in all entry points but also, probably most important, the interpreter with importable modules. An application is essentially an environment, where the user is only interested in the entry points provided by the package providing the application. That is how I distinguish the two.
Good questions! In my point of view a lockfile should aim to provide as much information that is needed to reproduce the environment. Best effort. It is inevitable it will be incomplete when
- certain system dependencies are needed that cannot be described using Python tooling;
- certain build flags are needed that also cannot be described with Python tooling;
- dependencies are needed that require authentication, and the user has no means to authenticate.
The first one is a general problem that I consider entirely out of scope. The second is only relevant for source builds. In my opinion this is similar as the first and out of scope. I think these two items are also best left to non-Python tooling to begin with, though hopefully in time they can cooperate/integrate better. The third, I actually don’t know the current state of this with Python tooling as I hardly use say pip myself these days. Auth should anyway be done at a different level. And about not having the credentials, well, that’s fine not? It’s essentially the same as someone yanks a release from PyPI.
That the existing lockfiles don’t lead to fully reproducible builds by itself is I think acceptable, since the available Python tooling is lacking for that. Though maybe there is more with pipenv, I have not checked.
If you consider other languages/frameworks, it is actually the same. None of them out there lead to actually reproducible builds by themselves. Haskell’s Stack can, when using it’s Nix integration. That these tools by themselves cannot create a reproducible build/environment/application is not a blocker the way I see it, you simply need way more information for that. But most of these tools do provide a good foundation that tools such as Nix and Guix and I am sure there is more tooling out can, with minimal effort, add additional information and make reproducible builds.
Of course that doesn’t help the average Python user. But therefore I think it is relevant to also offer the PEP 665 reproducible install and have that as the default for installers.