marker ordering is nondeterministic

[n-oden]

The ordering of system platform requirements in the marker section produced by poetry-plugin-export appears to be nondeterministic. Repeated invocations of poetry export --without-hashes -f requirements.txt in our project will at a roughly coin flip probability produce either of the following two requirement specs:

-colorama==0.4.6 ; (sys_platform == "win32" or platform_system == "Windows") and python_full_version == "3.9.21"
+colorama==0.4.6 ; (platform_system == "Windows" or sys_platform == "win32") and python_full_version == "3.9.21"

Obviously (a || b) && c and (b || a) && c are logically equivalent, so there's no problem here in terms of actually installing the project, but we have precommit hooks and CI tooling to ensure that requirements.txt is kept up to date with changes in poetry.lock, and the fact that the marker section may change arbitrarily is causing build and check failures.

Unfortunately this is also not currently easily possible to work around by using a "smarter" approach to checking equivalence with the existing packaging tooling; packaging.requirements.Marker.__eq__() appears to be a simple string comparison:

>>> from packaging.requirements import Requirement
>>> r1 = Requirement('colorama==0.4.6 ; (sys_platform == "win32" or platform_system == "Windows") and python_full_version >= "3.9.21"')
>>> r2 = Requirement('colorama==0.4.6 ; (platform_system == "Windows" or sys_platform == "win32") and python_full_version >= "3.9.21"')
>>> r1 == r2
False

Request: any (a || b) component of the generated marker should be sorted lexically.

[radoering]

This might be resolved by python-poetry/poetry-core#843 (which is in the main branch of poetry-core but not released yet).

Request: any (a || b) component of the generated marker should be sorted lexically.

I do not think we will do that but we aim for a deterministic order in the sense that two subsequent executions should return the same order.

[n-oden]

@radoering brilliant. Once that gets released I'll verify that the behavior is fixed.

[bnounours]

Hello,

I have the same issue (with same package indeed :p). As I export the requirements as pre-commit, it is complicated as is fails each time the file change.

So I am also interested by the fix :)

[heidimhurst]

Unfortunately I've found that even with the release of poetry 2.1.2 which has included the changes to make poetry-lock output deterministic (see python-poetry/poetry#10276), the results of exporting dependencies twice in a row is not always the same.

@n-oden - have you been able to resolve this issue? Or have you experienced a recurrence?

The context in which this arises for us is in CI pipelines where we check to make sure the dependencies are locked, and if so we export the requirements. Unfortunately due to this bug we're seeing false failures in our pipeline.

[danialkeimasi]

I have the same issue with poetry 2.1.3.

[radoering]

Do you have a minimal example to reproduce the issue (pyproject.toml and poetry.lock)?

[danialkeimasi]

Of course. Check this out:

https://gist.github.com/danialkeimasi/12d91d654bb0f99a4e1e7b5b8619fbb2

[Souf149]

A more minimal version is here:

[project]
name = "poetry-test-project"
version = "0.1.0"
description = ""
authors = [
    {name = "Souf",email = "metabyte149@gmail.com"}
]
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
    "uvicorn (>=0.38.0,<0.39.0)",
]

[tool.poetry]
packages = [{include = "poetry_test_project", from = "src"}]

[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

[dependency-groups]
dev = [
    "pytest-env (>=1.2.0,<2.0.0)",
]

[radoering]

By chance, I ran into this issue once. For those who are still experiencing this issue with Poetry 2.1.2 and later, python-poetry/poetry#10667 will probably fix it - given that you were experiencing nondeterministic markers only when exporting multiple groups.