Skip to content
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

Version matching bug (or feature)? #4729

Closed
2 tasks done
andras-kth opened this issue Nov 10, 2021 · 2 comments · Fixed by python-poetry/poetry-core#396 · May be fixed by python-poetry/poetry-core#379
Closed
2 tasks done

Version matching bug (or feature)? #4729

andras-kth opened this issue Nov 10, 2021 · 2 comments · Fixed by python-poetry/poetry-core#396 · May be fixed by python-poetry/poetry-core#379
Labels
kind/bug Something isn't working as expected

Comments

@andras-kth
Copy link

  • I have searched the issues of this repo and believe that this is not a duplicate.
  • I have searched the documentation and believe that my question is not covered.

Issue

The "weak equality" logic in poetry.core.semver.version.allows appears to treat non-local to local and local to non-local version comparison symmetrically. For example,

>>> from poetry.core.semver.helpers import parse_constraint
>>> local_version = parse_constraint('==1.10.0+cu113')
>>> public_version = parse_constraint('==1.10.0')
>>> public_version.allows(local_version)
True
>>> local_version.allows(public_version)
True
>>>

My expectation, apparently also supported by PEP 440, would be that the latter should evaluate to False.

If the specified version identifier is a public version identifier (no local version label), then the local version label of any candidate versions MUST be ignored when matching versions.

If the specified version identifier is a local version identifier, then the local version labels of candidate versions MUST be considered when matching versions, with the public version identifier being matched as described above, and the local version label being checked for equivalence using a strict string equality comparison.

https://www.python.org/dev/peps/pep-0440/#version-matching

What do you think? Is this a bug or a feature?
Or, perhaps, my interpretation of PEP 440 is wrong, and this is a compliant implementation...

@abn
Copy link
Member

abn commented Apr 27, 2022

I would say this is a bug. And that the following lines in core should be removed.

https://github.com/python-poetry/poetry-core/blob/b1cc9188fb8de8ab9104565392a54f9f4343a204/src/poetry/core/semver/version.py#L89-L90

I also suspect these lines (or similar) should be added to VersionRange.allows.

            elif _this.is_local() and (not _other.is_local() or _this.local != _other.local):
                return False

https://github.com/python-poetry/poetry-core/blob/b1cc9188fb8de8ab9104565392a54f9f4343a204/src/poetry/core/semver/version_range.py#L81-L83

This was introduced explicitly in the following PRs.

That said, I suspect the correct behaviour is to always ensure local tag is respected when compared, ie. that tag must exist even for public version identifiers are within allowed ranges. Eg: <=3.0.1+local.1 should disallow 3.0.0, 3.0.1 and 3.0.0+local.0 (this one i am a bit on the edge as this can be useful and is ambiguous in the spec); but allow 3.0.0+local.1 and 3.0.1+local.1.

@Secrus Secrus added the kind/bug Something isn't working as expected label May 18, 2022
abn added a commit to abn/poetry-core that referenced this issue May 26, 2022
Prior to this change, local label comparison was inconsistent with
PEP 440. This change ensures that the local version label is checked
for equivalence using a strict string equality comparison.

Resolves: python-poetry/poetry#4729
abn added a commit to abn/poetry-core that referenced this issue May 26, 2022
Prior to this change, local label comparison was inconsistent with
PEP 440. This change ensures that the local version label is checked
for equivalence using a strict string equality comparison.

Resolves: python-poetry/poetry#4729
Copy link

github-actions bot commented 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working as expected
Projects
None yet
3 participants