Deterministic installations from packages

[0x64746b]

• 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

[MokarromHossainTR]

+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.

[gsemet]

I propose this as an option —frozen-wheel

[gsemet]

I would still recommend to put it as option, and potentially give a different package name, since the generated package is not pip installable in an existing environment. Basically two different « frozen » app cannot live in the same environment since there are good chances that one at least of their deps will be pinned differently.

coupled with pipx however this would be perfect !

[0x64746b]

the generated package is not pip installable in an existing environment. Basically two different « frozen » app cannot live in the same environment

Just to be nitpicky here: the generated packages conceptually are installable into an existing environment (e. g. an empty one ;)), and two different frozen apps can be installed into the same environment (iff they don't contain different versions of the same dependency). Practically, that may or may not be an issue, which is why I argue for providing such an option 👍

[gsemet]

We are talking about the following problems:

• even if a correct version of a given shared dependencies CAN be found if both application are installed in the same “pip install”, people usually do not do that and install app when they need it. So your new application can install a version of a dependencies the other apps tells it does not want, and pip won’t notice.
• When the second “pip install” occurs, a new version of a dependency can be installed and broke the other app that was perfectly working so far.
• Package maintainer MAY not follow semver or pep440, so even the version range of each lib SHOULD NOT be trusted.

trust me. Everything is simpler when each app is it its own venv. And since it is optional, you do not have to use it if you feel everything I have told does not apply to you.

[BrandonLWhite]

Same as #2331

[finswimmer]

Duplicate of #2778

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.