-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
"Compatible Release" (~=) operator violates PEP 440 with long (4-part+) versions #3186
Open
3 tasks done
tharradine opened this issue
Oct 12, 2020
· 4 comments
· May be fixed by python-poetry/poetry-core#409
Open
3 tasks done
"Compatible Release" (~=) operator violates PEP 440 with long (4-part+) versions #3186
tharradine opened this issue
Oct 12, 2020
· 4 comments
· May be fixed by python-poetry/poetry-core#409
Labels
Comments
tharradine
added
kind/bug
Something isn't working as expected
status/triage
This issue needs to be triaged
labels
Oct 12, 2020
Update: It seems as though the issue runs deeper and also affects the Input:
Expected locked version:
Actual locked version:
|
I didn't know that one could use PEP 440 operators for version specification in Poetry. This is not currently documented, but I think it should be. |
1 task
2 tasks
PTAL @dimbleby @radoering |
report looks legit, I see we already have python-poetry/poetry-core#409. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
-vvv
option).poetry debug output
Issue
It seems as though when specifying a dependency with a 4-part (or possibly higher) version number, that the
~=
operator violates PEP 440. An example is included in my pyproject.toml and poetry.lock.Specifically, when locking:
Input:
anchor-exp = "~=0.0.0.5"
Expected locked version:
anchor-exp = "==0.0.0.6"
Actual locked version:
anchor-exp = "==0.0.2.0"
This does not match the example shown in PEP 440:
Current workaround
Specify the correctly resolved version constraints manually (e.g.Edit: It seems as though doing this results in the same version, which tells me the issue could actually be in the version-matching withanchor-exp~=0.0.0.5
->anchor-exp>=0.0.0.5,==0.0.0.*
). This works fine for primary dependencies, but may be problematic with transitive dependencies.*
. Actual workaround can beanchor-exp~=0.0.0.5
->anchor-exp>=0.0.0.5,<0.0.1
The text was updated successfully, but these errors were encountered: