Deterministic installations from packages
See original GitHub issue- I have searched the issues of this repo and believe that this is not a duplicate.
- I have searched the documentation and believe that my question is not covered.
Feature Request
Hi y’all,
I built a simple application that I would like to package, so that when deployed (in my case installed into a Docker image) I don’t have to manually copy source files into the file system, but can rely on the package manager to handle standard compliant placement (scripts in $PATH
, importable modules in $PYTHONPATH
).
However, when packaging my code, the .lock
file seems to be ignored (the same way setuptools
would do), and the METADATA
in the *.dist-info/
dir only list the direct dependencies specified in the project toml. This means that any installation not happening from the source, but from a derived wheel, will be non-deterministic, losing all associated benefits.
Since poetry already resolved and pinned the transitive dependencies of the project, I think it would be great if the build
command could be instructed to replace the direct dependencies (which usually contain ranges of accepted versions) listed in the project toml with all the materialized pinned versions from the .lock
file.
This way, easily distributable packages could still produce deterministic installations (obviously that would put the burden of avoiding version conflicts in the target environment through some means of isolation onto the consumer).
Thanks for considering and the sleek tool dtk
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (1 by maintainers)
+1 I’m having the same issue. It would be a great feature if poetry build command respects .lock file while writing dependency in the METADATA.
I propose this as an option —frozen-wheel