Repository navigation
Breaking change in handling of some version constraints from poetry-core 1.0.0 to 1.1.0 #6519
Description
- I am on the latest Poetry version.
- I have searched the issues of this repo and believe that this is not a duplicate.
- If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption).
- OS version and name: Mac OS X 11.6 (BigSur)
- Poetry version: 1.1.14 -> 1.2.0
- Link of a Gist with the contents of your pyproject.toml file:
Issue
I ran into an interesting bug (I'm not sure if it's the root cause of some other issues, I had trouble finding a matching issue) where when poetry was using poetry-core==1.0.0 it was correctly resolving the version constraint of a somewhat non-standard semver version, but once poetry started using version poetry-core==1.1.0, it's no longer correctly resolving the same version constraint, resulting in dependency resolution issues because the resolved constraint is never satisfiable.
For more context, in my current project, I'm pulling in a library:
opentelemetry-instrumentation-fastapi = "^0.32b0"
Where the next available version is 0.33b0.
In a version of poetry that uses poetry-core==1.0.0 , it correctly resolves this constraint:
# pip install poetry-core==1.0.0
# python <<EOF
from poetry.core.semver import parse_constraint
print(parse_constraint("^0.32b0"))
EOF
This will output >=0.32b0,<0.33, which is what ultimately ends up in setup.py when publishing with poetry.
Now, using poetry-core==1.1.0:
# pip install poetry-core==1.1.0
# python <<EOF
from poetry.core.semver.version import Version
print(Version.parse("0.32b0").next_breaking())
EOF
This will output 0.32, which ultimately will get translated to a constraint that's unsolvable >=0.32b0,<0.32 in setup.py:
install_requires = \
['fastapi-versioning>=0.10.0,<0.11.0',
'fastapi>=0.79.0,<0.80.0',
'gprof2dot>=2022.7.29,<2023.0.0',
'opentelemetry-instrumentation-fastapi>=0.32b0,<0.32', # <-- here
'opentelemetry-instrumentation-logging>=0.32b0,<0.32', # <-- and here
'requests>=2.27.1,<3.0.0',
'splunk-opentelemetry[all]>=1.7.0,<2.0.0',
'starlette-exporter>=0.14.0,<0.15.0',
'uvicorn[standard]>=0.18.2,<0.19.0']
Ultimately, after upgrading to poetry version 1.2.0 and publishing my package, it could no longer be installed because this version constraint could no longer be satisfied, resulting in a breaking change. I've worked around this for now by specifying an explicit version constraint, but, wanted to see if this is something that anyone else has noticed, if this is a "won't fix" type situation, since the version is somewhat non-standard, etc.
Activity
dimbleby commentedon Sep 14, 2022
feels like a bug in Version.next_breaking() to me.
I guess it's correct that
"0.32b0".next_minor()is"0.32", butnext_breaking()should give"0.33"If you care enough to put together a fix: suggest that
next_breaking()wants to start by goingstable = self.stableand then considerstableeverywhere it currently considersself.And add a testcase in here -
next_breaking()has no coverage at the moment so the more the merrier, cf the tests fornext_major()andnext_minor()and suchlike.dimbleby commentedon Sep 14, 2022
though fwiw
>=0.32b0,<0.32is not unsolvable: it allows0.32b0(and0.32b1, etc)mazinesy commentedon Sep 16, 2022
👋 Just adding on top of this,
>0.0.2-alpha.21yields>0.0.2-alpha.21,<0.0.2on1.2.0but works fine on1.1.15dimbleby commentedon Sep 16, 2022
should be straightforward to fix and test, see my comment a couple up if this is important to you
mazinesy commentedon Sep 16, 2022
@dimbleby Opened python-poetry/poetry-core#475
mazinesy commentedon Sep 16, 2022
@dimbleby Looking at the PR, is that really the problem ? The issue I had was:
We have a package with
sqlalchemy2-stubs=^0.0.2-alpha.21and when building the wheel, it resolved into the following constraint:which seems fine since
0.0.2-alpha.21 < 0.0.2. Butpoetry 1.2.0was unable to resolve it.On
poetry 1.1.15, building the wheel resulted in the following constraint:I believe that the correct upper limit after a prerelease is the release itself which is
0.0.2. This would imply that the bug is not in thisnext_breaking()but rather somewhere where the constraints is actually computed. 🤔dimbleby commentedon Sep 16, 2022
I just tried it and poetry successfully resolves
sqlalchemy2-stubs = "^0.0.2-alpha.21"tosqlalchemy2_stubs-0.0.2a27.Please provide a repro of whatever your problem is!
dimbleby commentedon Sep 16, 2022
Are you reporting that when you try to
pip installthe wheel afterpoetry build, pip does not agree with poetry about version ordering?it seems to me that pip is wrong and poetry is right here:
so if that is what you are talking about, I'd suggest taking it to the pip issue tracker for an opinion
dimbleby commentedon Sep 16, 2022
although I could imagine that poetry was supposed to normalize the version before writing it
edit: that doesn't help, you still get
so this really does want taking to pip IMO
dimbleby commentedon Sep 16, 2022
hmm, beginning to change my mind...
PEP440 says "The exclusive ordered comparison <V MUST NOT allow a pre-release of the specified version unless the specified version is itself a pre-release"
So "<0.0.2" does indeed exclude all those prereleases...
possibly the bottom line here is that no-one really knows what "^0.0.2a21" is supposed to mean, the caret notation is a thing that poetry introduces and so this is a problem of its own making.
python-poetry/poetry-core#475 seems like the right answer
mazinesy commentedon Sep 19, 2022
Alright! But if you want to replicate the issue, here's where to start:
sqlalchemy2-stubs^0.0.2-alpha.21like this:From that state, you need another
poetryproject that depends onmypkg. This yields an error that basically says:dimbleby commentedon Sep 19, 2022
yep, I think we're all on the same page now.
If you can get python-poetry/poetry-core#475 over the line everything should be good
github-actions commentedon Mar 1, 2024
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.