Support poetry.lock #835
Support poetry.lock #835
Conversation
cjolowicz
force-pushed
the
poetry-lock
branch
2 times, most recently
from
22005a2
to
143d0f8
Compare
cjolowicz
force-pushed
the
poetry-lock
branch
from
41083eb
to
88427c7
Compare
|
Rebased onto master (
|
|
Rebased onto master (af860be) |
|
Poetry 1.0.0b2 was released on 2019-10-11: |
|
Poetry 1.0.0b3 was released on 2019-10-25: |
|
Poetry 1.0.0b4 was released on 2019-11-08: |
cjolowicz
force-pushed
the
poetry-lock
branch
from
ae5b3cd
to
3998f12
Compare
|
|
Hey @CaseyFaist, are you still planning to merge this series of PRs? If so, do you have an approximate ETA? Thanks! |
Add two test cases for projects using poetry as the build backend: - testPoetry: project without dependencies - testPoetryLock: project with dependencies, using a poetry.lock file
Add two test cases for projects using flit as the build backend: - testFlit: project without dependencies - testFlitRequires: project with dependencies
Check that pinned requirements are honored when poetry.lock is present. Request an outdated version of marshmallow in poetry.lock (3.0.0). Check that the outdated version is installed, rather than a newer version also satisfying the version constraint in pyproject.toml (^3.0.0).
Install pyproject.toml-based projects using `pip install .`. Do not use a requirements.txt for this. The requirements.txt file is needed to handle pinned versions extracted from the poetry.lock file. Note that we cannot simply append `.` to the exported requirements.txt file. Currently pip requires that either all requirements have a hash or none. Including `.` would thus force us to omit hashes for all requirements.
If a poetry.lock file is present, use the Poetry CLI to export the pinned requirements to a requirements.txt file. If the project already contains a requirements.txt, use that and ignore poetry.lock. Poetry is not used to install the project because it does not clean up stale requirements. This means that requirements need to be exported anyway, for the `pip-uninstall` step. Since we only use Poetry to export a requirements.txt file, ignore the Poetry version specified in pyproject.toml. Install a pre-release of 1.0.0 because the export command is not available before 1.0.0a0. Note that supporting pyproject.toml-based installations is not enough to handle pinned requirements: When pip installs a pyproject.toml-style project using the process described in PEP 517, it only uses Poetry to build a wheel. The wheel contains the version constraints from pyproject.toml, not the pinned versions from poetry.lock.
cjolowicz
force-pushed
the
poetry-lock
branch
from
3998f12
to
cd23a90
Compare
|
Poetry 1.0.0b8 was released a few days back (fixes at least one bug) |
|
Poetry 1.0 was officially released today, formalizing the export command. |
|
Could someone give us an idea of when this PR will be merged ? |
|
A stop-gap solution: https://elements.heroku.com/buildpacks/moneymeets/python-poetry-buildpack |
|
What does heroku currently default to (prior to this PR being merged) if their is a |
|
@yunti this PR is nowhere near to be merged, so if both files are present currently Heroku defaults to using |
There was a problem hiding this comment.
Hi! Thank you for the PR. We're in the process of moving to Cloud Native Buildpacks, so all development effort is focused there at the moment, and eventually they will replace the current buildpacks. As such, we're only making minimal changes to the current buildpacks for now.
For more information, see:
#834 (review)
Export pinned requirements from
poetry.locktorequirements.txt. This PR is a follow-up to #833 and #834.If a
poetry.lockfile is present, use the Poetry CLI to export the pinned requirements to arequirements.txtfile. If the project already contains arequirements.txt, use that and ignorepoetry.lock.Install
pyproject.toml-based projects usingpip install ., instead of creating arequirements.txtcontaining.. Therequirements.txtfile is needed to handle pinned versions extracted from thepoetry.lockfile.Closes #796
CI is broken for PRs from another repository, see this comment. Please check the corresponding PR in my fork to verify CI:
Why is this necessary at all, after supporting PEP 517 installations?
Note that supporting
pyproject.toml-based installations is not enough to handle pinned requirements: When pip installs apyproject.toml-style project using the process described in PEP 517, it only uses Poetry to build a wheel. The wheel contains the version constraints frompyproject.toml, not the pinned versions frompoetry.lock. See python-poetry/poetry#537Why not use Poetry to install?
Poetry is not used to install the project because it does not clean up stale requirements. This means that requirements need to be exported anyway, for the
pip-uninstallstep. See python-poetry/poetry#648Why use Poetry 1.0.0b1 instead of the version specified in pyproject.toml?
Since we only use Poetry to export a
requirements.txtfile, ignore the Poetry version specified inpyproject.toml. Install a pre-release of1.0.0because the export command is not available before1.0.0a0.Update: Poetry 1.0.0 has been released. Also, the version specified in
pyproject.tomlis a minimum version, so it would not make sense to install it anyway.Why not append
.to the exported requirements file?Note that we cannot simply append
.to the exportedrequirements.txtfile. Currently pip requires that either all requirements have a hash or none. Including.would thus force us to omit hashes for all requirements. See pypa/pip#4995Test case
Add a test to check that pinned requirements are honored when
poetry.lockis present. Request an outdated version ofmarshmallowinpoetry.lock(3.0.0). Check that the outdated version is installed, rather than a newer version also satisfying the version constraint inpyproject.toml(^3.0.0).