@abravalheri indeed the requires-python change might be harder to make optional. The build system is just the only place that could add such a file, so if it doesn’t implement it, it would be still okay as the existence of the file is optional.
Well actually that is what we are doing: We use own index with self curated packages. That’s why there is
A package installer SHALL require user confirmation if any requirement in the lock file is to be installed from a source different from the one used for the original wheel.
Which gets significantly harder when the lock file is not coming from an index.
The original can be found in the Diff (Rev 5 vs Rev 6) of the first original thread.
This got lost by switching threads:
After reading some of the replies, I realized the discussion has shifted more toward the topic of application deployment.
Because of that, I’ve rewritten the original post (please have another look before continuing the discussion), starting more strongly from the use cases and clearly limiting the scope.
As was pointed out creating an application is a much different problem scope, therefore I revisited the reasons for my idea of adding the lock file to wheel. They are more about defining a common way to be able to distribute/use a lock file to reproduce the environment a package was tested with and therefore is safe to install.
But I feel like we are to many different things are open or understood differently in order to forward with answering that question.
Maybe at a later point some else takes it from here or at least knows what not to do.
I will probably create an internal tool that does include a lock file in wheel and installs it from there, because it really suits my personal use case.
It just seemed straight forward and easy to me, that I thought why not propose it as general way.
At least now I understand why that not as easy as thought.