Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

poetry build --format=wheel --dependencies=locked #4788

Closed
tardyp opened this issue Nov 17, 2021 · 3 comments
Closed

poetry build --format=wheel --dependencies=locked #4788

tardyp opened this issue Nov 17, 2021 · 3 comments
Labels
kind/feature Feature requests/implementations

Comments

@tardyp
Copy link

tardyp commented Nov 17, 2021

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

@tardyp tardyp added kind/feature Feature requests/implementations status/triage This issue needs to be triaged labels Nov 17, 2021
@abn
Copy link
Member

abn commented Nov 17, 2021

Related: python-poetry/poetry-core#71

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.

@tardyp
Copy link
Author

tardyp commented Nov 19, 2021

thanks @abn browsing this PR made me found another open issue that is not close, so I am gonna mark this as duplicated for #2778

@tardyp tardyp closed this as completed Nov 19, 2021
@abn abn removed the status/triage This issue needs to be triaged label Mar 3, 2022
Copy link

github-actions bot commented Mar 2, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/feature Feature requests/implementations
Projects
None yet
Development

No branches or pull requests

2 participants