You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like it did not get new attention from maintainers as it is a closed issue, but the suggestion from @Tobotimus looks pretty decent to me.
Problem statement
The problem is that poetry build by design creates packages that reflect the dependencies as in pyproject.toml.
For application continuous deployment, some find it handy use a wheel as a build artifact, that is transported around the CI/CD pipeline
Some application workflow:
without docker
use CI to run tests and lints
if all OK then run poetry build
copy wheel to server
create new virtualenv
pip install wheel in new virtualenv
if everything is fine then switch from old venv to new
with docker
use CI to run tests and lints
if all OK then run poetry build in the same env as the tests
have a simplistic docker image that just pip install that wheel expecting tested dependencies to come with it
with pipx
Some use pipx and private pipy servers to distribute apps to internal customers.
In this case, this make sense to pin the tested dependencies inside the wheels.
With those workflows, currently, build and tests run against poetry.lock, but wheel installation install latests available and theoretically compatible packages. Then few month later, prod goes kaboom and everyone is sorry.
Current solution to this problem is to generate wheel and requirement.txt, so that we need to pip install app.wheel --contraints requirement.txt.
Feature Request
poetry build --format=wheel --dependencies=locked
This would just add all the pin dependencies in the wheel instead of the one from the pyproject.yaml
The text was updated successfully, but these errors were encountered:
The suggestion here is to work at the poetry level. Which can be a good alternative. There are trade-offs for both approaches.
One thing to consider here is if an option like this should always yield wheel with a local tag (project-1.0.0+locked). Otherwise we can end up with two different build artifacts.
Several attempts have been made to unburry #1307
It looks like it did not get new attention from maintainers as it is a closed issue, but the suggestion from @Tobotimus looks pretty decent to me.
Problem statement
The problem is that poetry build by design creates packages that reflect the dependencies as in pyproject.toml.
For application continuous deployment, some find it handy use a wheel as a build artifact, that is transported around the CI/CD pipeline
Some application workflow:
without docker
with docker
with pipx
Some use pipx and private pipy servers to distribute apps to internal customers.
In this case, this make sense to pin the tested dependencies inside the wheels.
With those workflows, currently, build and tests run against poetry.lock, but wheel installation install latests available and theoretically compatible packages. Then few month later, prod goes kaboom and everyone is sorry.
Current solution to this problem is to generate wheel and requirement.txt, so that we need to
pip install app.wheel --contraints requirement.txt
.Feature Request
This would just add all the pin dependencies in the wheel instead of the one from the pyproject.yaml
The text was updated successfully, but these errors were encountered: