-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
does not include locked transitive dependencies in METADATA/PKG-INFO
#2331
Closed
2 tasks done
Labels
kind/feature
Feature requests/implementations
Comments
BrandonLWhite
added
kind/bug
Something isn't working as expected
status/triage
This issue needs to be triaged
labels
Apr 20, 2020
finswimmer
added
kind/feature
Feature requests/implementations
and removed
kind/bug
Something isn't working as expected
status/triage
This issue needs to be triaged
labels
Apr 21, 2020
Duplicate of #2778 |
This was referenced Jul 18, 2022
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
-vvv
option).Issue
When generating a pip-installable package using
poetry build
, the resulting packages's metadata does not include all of the locked dependencies. Therefore, subsequent installation of the published package will not adhere to the pinned versions in the poetry.lock file.Examining the Poetry source code, it seems that only the top-level dependencies from pyproject.toml are conveyed in the
Requires-Dist:
of the wheel METADATA and sdist PKG-INFO. This is probably desirable for library packages that are not standalone applications.However, the use case I am currently dealing with involves command-line interface (CLI) tools meant to be installed using
pipx
(which isolates and runs in dedicated virtualenv). We are also using a private PyPI repository (JFrog/Artifactory) though that is irrelevant to the issue. The pip-toolspip-compile
serves well in this regard -- the frozen requirements.txt feeds the setup.py sdist bdist_wheel operation and the locked/frozen/pinned dependency flattened tree lands in the METADATA/PKG-INFO. So users simply runpipx install foo-cli
and get the exact package versions.We're auditioning Poetry for our various workflows and this is blocking us from adopting Poetry for use with many of our applications where we need to publish the frozen requirements in the package meta.
In my opinion, Poetry's default behavior when building should be to use the lockfile's dependencies when generating the distribution. If a lock didn't the fallback would be to use pyproject.toml's deps (the current behavior). There could also be a
--no-lock
type option to control this behavior for the case where you want to publish libraries for reuse. The defaults could also be flipped around, where the current--no-lock
remains the default and publishing the locked tree requires adding--lock
.The text was updated successfully, but these errors were encountered: