-
Notifications
You must be signed in to change notification settings - Fork 362
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
Add Poetry buildpack #972
base: main
Are you sure you want to change the base?
Add Poetry buildpack #972
Conversation
Thanks for submitting your first pull request! You are awesome! 🤗 |
89f5ed6
to
d4db6b0
Compare
Hi @betatim, just poking you in case the PR fell a bit too far down the todo list 😛 no rush though! Oh and Happy New Year! |
Heavily based off of the pipfile buildpack
d4db6b0
to
ba4ce90
Compare
Rebased onto main since there were some conflicts |
Not just likely; specifying the Python version is mandatory. From here:
|
As suggested in the issue #835 this PR adds in a poetry buildpack.
This is heavily based on the implementation of the Pipenv buildpack, since they're pretty similar anyway. I've also implemented equivalent tests to what is done for pipenv.
The only large issue with this PR is how the python versioning is worked out in the buildpack. Poetry lets you specify dependency constraints using a variety of symbols (e.g.
^
,*
,~
), and it's likely that python was specified with these requirements.To handle these constraints poetry-core has a
semver
module which is what I use to parse the versions constraints, however this means thatpoetry-core
would then be a dependency requirement for repo2docker. I really don't like adding this dependency in, but the alternative is to either re-implement this constraint system, include a copy of thepoetry.core.semver
module in the poetry buildpack, or to ignore the constraints and parse them naively. Does anybody have a better way to deal with this?