Poetry seems to be resolving the wrong dev package version

[erichjzimmerman]

I am currently using Poetry 1.1.14 (not the latest). Honestly, the jump from 1.0.x to 1.1.x was difficult, so we're not in a big hurry to get to 1.2.x, although I'm sure we will eventually.

We are installing from a local repository, which has the following packages:

• 15.0.0b14 20-04-22 10:19:18 -0700
• 15.0.0b14.dev1+swpbl181056normalizingversion.9f23458d/ 18-04-22 17:08:37 -0700
• 15.0.0b14.dev2+swpbl181056normalizingversion.e923ccf4/ 19-04-22 14:47:52 -0700
• 15.0.0b14.dev3+swpbl181056normalizingversion.e6c164cd/ 19-04-22 16:51:42 -0700
• 15.0.0b14.dev4+swpbl181056normalizingversion.b145f667/ 20-04-22 10:06:41 -0700

In our pyproject.toml, we specify:
my-testcore = "15.0.0b14"

When I try poetry lock -vvv, eventually I see the following line:
private: 1 packages found for sonos-testcore 15.0.0b14

And later, when dependencies are being resolved, I see
1: fact: my-testcore (15.0.0b14.dev1+swpbl181056normalizingversion.9f23458d) depends on allure-pytest (2.6.5)

Apparently, it is resolving to that dev package, when I would THINK it would resolve to the non-dev package if one is available (15.0.0b14).

We don't seem to run into this problem when using non-beta version (e.g. 16.0.0 vs 15.0.0b14), so I'm wondering if there is an issue with the resolution process.

Is this expected behavior, and I'm just not doing something right?

It's complicated, because we are using pre-release versions AND dev packages, so I'm just trying to navigate this.

Thanks!

[neersighted]

I'll have to ask @dimbleby or @radoering to confirm, but I suspect it's the use of local labels, which are defined by PEP 440 to be considered a newer version than a version without a local label, as I understand it.

[erichjzimmerman]

This makes a lot of sense, as I understand local labels better now (and their purpose).

I guess, though, the question is how that string of segments would be prioritized:

1. 2.0.0b3
2. 2.0.0b3.dev3
3. 2.0.0b3.dev3+localbuildstring-hash

I understand why version 3 would be considered newer than version 2 according to PEP 440.

But it seems like version 1 would be considered newer than version 2 because it removes the dev build segment

Which would seem to make the relationship between 1 and 3 a bit nebulous? It is apparent that Poetry is resolving 3 as the newest of the group, but I am tempted to contend that because 3 is a local label on a dev build, that 1 would take precedence.

[neersighted]

1 should be newer than 2, but I think what is happening is we consider local versions before version numbers with these multi-segment versions. The code is currently a little idiosyncratic and incorrect in some edge cases, the interaction of multi-segment versions and local labels could certainly be one of them.

[erichjzimmerman]

Thanks for chiming in on this, @neersighted , I appreciate it.

Summarizing based on the above:
Poetry honors 1 being newer than 2 (I don't actually have this scenario wired up, but Poetry handles the non-local conditions pretty consistently) -- correct behavior
Poetry honors 3 being newer than 2 -- also correct behavior
Poetry considers 3 to be newer than 1, which IMO is technically incorrect, because the non-Dev segment package should always (?) be newer than the dev segment package.

I can take some time to test this more thoroughly on poetry 1.2 to see if it still holds (a cursory attempt indicated that it does), and I can also provide more thorough steps and create a bug if needed. I posted here just to get a sense for what was expected to happen.

[radoering]

At least, version comparison doesn't seem to be the issue:

from poetry.core.constraints.version import Version

beta = Version.parse("2.0.0b3")
beta_dev = Version.parse("2.0.0b3.dev3")
beta_dev_local = Version.parse("2.0.0b3.dev3+localbuildstring-hash")

assert beta_dev_local > beta_dev
assert beta > beta_dev
assert beta > beta_dev_local

All of the asserts pass.

[neersighted]

Interesting -- it looks like more introspection is needed in order to figure out what is happening.

[radoering]

Can you reproduce it with poetry 1.2? (There have been many bugfixes, some also concerning the handling of pre-releases.)

[erichjzimmerman]

I can reproduce it in 1.2.2, but given the above conversation, it may be "by design."

[radoering]

Works for me. I set up an index with some dummy packages. If I specify my-testcore = "15.0.0b14" in pyproject.toml then "15.0.0b14" is locked. If I specify my-testcore = "<15.0.0b14" then "15.0.0b14.dev4+swpbl181056normalizingversion.b145f667" is locked.

The full output of poetry lock -vvv may provide some further insights.