-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
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
- 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