Version Matching - Local Identifiers

• Poetry version: 1.1.13 -> 1.2.1
• Python version: 3.9.10
• OS version and name: macOS 12.5.1
• pyproject.toml: Gist

• [ x] I am on the latest stable Poetry version, installed using a recommended method.
• [ x] I have searched the issues of this repo and believe that this is not a duplicate.
• [ x] I have consulted the FAQ and blog for any relevant entries or release notes.
• [ x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

I believe this issue is similar to https://github.com/python-poetry/poetry/issues/4729 but didn’t consider it a duplicate because the issue is marked as closed.

This issue might be fixed up: https://github.com/python-poetry/poetry-core/pull/379

from poetry.core.semver.helpers import parse_constraint

dev_build = parse_constraint('==0.92.0+f4f0e5bc')
release_build = parse_constraint('==0.92.0')

release_build.allows(dev_build)
True

dev_build.allows(release_build)
False

release_build.next_breaking()
<Version 0.93.0>

dev_build.next_breaking()
<Version 0.93.0>

On version 1.1.13 adding a dependency to the pyproject.toml would always result in that specific version being written to the poetry.lock when running poetry lock --no-update.

After upgrading to 1.2.1 we noticed that adding a pinned version of an internal library to the pyproject.toml file and running poetry lock --no-update would result in the lock file containing a pointer to the expected version, but it would include the local identifier.

The poetry.lock would look like the example below.

[[package]]
name = "other-internal-project"
version = "0.92.0+f4f0e5bc"
description = ""
category = "main"
optional = false

A workaround that we found was adding the source to the pyproject.toml. Package versions with local identifiers are published to the local-pypi-snapshot PyPI instance and versions without are published to local-pypi-release.

other-internal-project" = {version = "0.92.0", source = "local-pypi-release"}

[neersighted]

That is correct in the local -> global direction, but as I understand your issue (you’re getting local versions when you don’t request them), you’re talking global -> local. If you request X.Y.Z, X.Y.Z+local is a valid way to provide it. I probably should have been more specific in my answer that I am only talking about the specific case of not specifying a local identifier.

[bradleyhurley]

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

Doesn’t the version matching section of PEP440 state they should be treated as different versions?

The examples in issue #4729 that is indicated as a bug seem to also indicate the versions should be treated as distinct.