heroku-buildpack-python
heroku-buildpack-python copied to clipboard
heroku
Support poetry.lock
Export pinned requirements from poetry.lock to requirements.txt. This PR is a follow-up to #833 and #834.
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.
Install pyproject.toml-based projects using pip install ., instead of creating a requirements.txt containing .. The requirements.txt file is needed to handle pinned versions extracted from the poetry.lock file.
Closes #796
CI is broken for PRs from another repository, see this comment. Please check the corresponding PR in my fork to verify CI:
- cjolowicz/heroku-buildpack-python#7
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 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. See sdispater/poetry#537
Why 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-uninstall step. See sdispater/poetry#648
Why use Poetry 1.0.0b1 instead of the version specified in pyproject.toml?
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.
Update: Poetry 1.0.0 has been released. Also, the version specified in pyproject.toml is 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 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. See pypa/pip#4995
Test case
Add a test to 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).
Poetry 1.0.0b2 was released on 2019-10-11:
https://github.com/sdispater/poetry/releases/tag/1.0.0b2
Poetry 1.0.0b3 was released on 2019-10-25:
https://github.com/sdispater/poetry/releases/tag/1.0.0b3
Poetry 1.0.0b4 was released on 2019-11-08:
https://github.com/sdispater/poetry/releases/tag/1.0.0b4
- Rebased onto master (93a620e6edacde750d32af6e3c8c3ad5e6800a40)
- Upgrade to Poetry 1.0.0b7 (03e27237193405f4ce017fe107b7ea7154aa5883)
- Minor cleanup (3998f12508bfe2245da76e3b0b10b8b0421180b1)
Hey @CaseyFaist, are you still planning to merge this series of PRs? If so, do you have an approximate ETA? Thanks!
Poetry 1.0 was officially released today, formalizing the export command.
Could someone give us an idea of when this PR will be merged ? Thank you.
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 pyproject.toml file and a requirement.txt file (that has previously been generated with poetry export ..)? Does it currently pick up and use that hashed and fully resolved requirement.txt?
@yunti this PR is nowhere near to be merged, so if both files are present currently Heroku defaults to using requirements.txt - that’s what we did before writing our own overlay buildpack.