python_version constraint included in exported requirements.txt

[blueyed]

I am seeing a difference in requirements.txt exported on CI:

% pdm export -f requirements -o "requirements/dev.txt.tmp" --dev --no-default -G dev -G checkqa
The exported requirements file is no longer cross-platform. Using it on other platforms may cause unexpected result.
…
-typing-extensions==4.0.1 \
+typing-extensions==4.0.1; python_version >= "3.10" \
     --hash=sha256:7f001e5ac290a0c0401508864c7ec868be4e701886d5b573a9528ed3973d9d3b \
     --hash=sha256:4ca091dea149f945ec56afb48dae714f21e8692ef22a395223bcd328961b6a0e
…

This constraint (; python_version >= "3.10") does not show up in prod's requirements (via pdm export -f requirements -o "requirements/prod.txt.tmp" --prod -G :all), but typing-extensions is included there also, (at least) via django-stubs-ext:

[[package]]
name = "django-stubs-ext"
version = "0.3.1"
requires_python = ">=3.6"
summary = "Monkey-patching and extensions for django-stubs"
dependencies = [
    "django",
    "typing-extensions",
]

It's likely via/caused by black, which is in "checkqa" dev-dependencies:

[[package]]
name = "black"
version = "21.12b0"
requires_python = ">=3.6.2"
summary = "The uncompromising code formatter."
dependencies = [
    "click>=7.1.2",
    "mypy-extensions>=0.4.3",
    "pathspec<1,>=0.9.0",
    "platformdirs>=2",
    "tomli<2.0.0,>=0.2.6",
    "typing-extensions!=3.10.0.1; python_version >= \"3.10\"",
    "typing-extensions>=3.10.0.0",
]

IIRC I've seen this diff/change before locally also, and it was fixed by removing ~/.cache/pdm then.

Both locally and on CI Python 3.10.1 is used.

Using pdm 1.12.2.

[frostming]

Can't reproduce this locally, can you make a reproducible example?

[blueyed]

I could reproduce it locally now only after rm ~/.cache/pdm, which makes sense since this is used on CI.
I can look into trying to make a reproducible example later, but it likely involves an empty cache and using black.

[blueyed]

Thank you for addressing it.
However I am not sure if the fix is proper: shouldn't the classifier be included after all, so that it only gets installed if it matches? (i.e. the requirements file would behave different on another Python version for example).
Is this covered by "The exported requirements file is no longer cross-platform. Using it on other platforms may cause unexpected result." then also/already?

(See the related test adjustment, which was done in the later commit: a32505d#diff-8b2ccaf13f2efef9c101b31c9926ba110343241d971d244ef11f4450cbc37c5c)

Given that removing the cache before generating the export seemed to fix it (by adding the classifier), it seemed like it would use something wrong (without the classifier) from the cache.

While not exporting the classifier unifies the result, are you sure that's the way to go?

[frostming]

Yup, The exported requirements.txt is no longer cross-platform and cross-python and keeping the environment markers(the correct name for "classifiers") is meaningless. Just remove them to make it look consistent, like what pip freeze gives.