Option to use lockfile dependencies in wheel instead of pyproject.toml versions

[couling]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

What

I'd like an option to use lockfile dependencies in built wheel instead of pyproject.toml versions. I want to be able to build a wheel with poetry, install it with any python package manager (even pip) and end up with the same dependencies as I would have through by invoking poetry install.

At the moment dependencies written into a wheel metadata are pretty much passed through from pyproject.toml (largely) unadulterated. I want an option to explicitly use the versions (and only those versions) in pyproject.lock as the dependencies of the wheel.

Why

I'd like this so that we can clean up a fuzzy boundary between poetry being an amazing development tool (it really is very good!) and a rather mediocre distribution / deployment deployment tool. This fuzzy line also makes it tricky to have a clear boundary between source and artefact in some contexts.

I don't think poetry ever tried to be a distribution / deployment tool. I don't think it was necessarily envisaged that poetry would need to be installed on the target [eg: end user's machine etc].

However this is what's happening in the wild because of one feature of poetry: the lock file. The lock file is so good that people want to keep using it downstream right onto the target machine as well. Right now the only way to do this is to copy the source onto the target machine, install poetry, and execute poetry install.

That's because at the moment the lockfile information is not embedded into the wheel. If you built the wheel and just distributed that the target environment would end up with different dependencies.

Example use case

One concrete use case is building docker images. I don't think lockfiles were ever intended as a way to ensure that docker images contained the same dependencies as the development project.

But some of us do have a real requirement to ensure our docker images build exactly as we intended them to.

If you look through poetry issues, you'll find a good few people complaining that installing poetry in a docker image is complex and messy. (though it has admittedly improved in versions between 1.1 to 1.3)

Closing remarks

I'd like to humbly suggest that poetry doesn't need to take any interest in building docker images into account. This should not generally be supported. There is a very rich and diverse set of tools for installing a wheel that work cleanly inside of docker with very little work.

If there were just an option to use the lockfile dependencies in the wheel, then poetry could remove the shackles of being a makeshift deployment tool.

[dimbleby]

duplicate #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.