Maybe worth mentioned a old attempt, that was cancelled:

• The great python3.8 purge [1] (python == 3.5)  #312552

From fabaff:

I don't agree with removing pythonOlder only because it mention "3.5". It should stay as it in many cases it was added manually and helps to track in some ways the state of the module in Nixpkgs. Same as going for modules which still use sha256, mention format = "setuptools"; or have six in their inputs.

While checking a couple of modules it showed that the entry is simply outdated. During mass updates pythonOlder is not checked. Also, upstream is not always aware what releases their module actually support and it doesn't have to align us. If upstream says python_requires=">=3.5" then our pythonOlder entry does reflect hat.

At this stage it would be great to get some feedback from @mweinelt and @natsukium on whether the change in this PR is wanted in general.

whether the change in this PR is wanted in general.

and whether the PR itself is wanted

Ight, @Sigmanificient @wolfgangwalther @fabaff (maybe also @GaetanLepage), what's yall's verdict on this: worth keeping or not?

From my perspective, this is certainly worth doing / keeping - but I feel like I lack the knowledge to tell why these conditions are there in the first place. If they are essentially similar to meta.broken in that they only concern combinations of in-tree python interpreters and these packages - then they should be removed, if the interpreter version is not there anymore. If there is more to them.. then maybe not. Is there more to them?

essentially similar to meta.broken in that they only concern combinations of in-tree python interpreters and these packages

yes, sorta: when a disabled package is evaluated, it errors with "PACKAGE doesn't support Python PYTHONVERSION", except it's Python-specific and is thus a top-level attr instead of meta one

I am in favor of such a change. I don't think we are missing much of getting rid of these evaluation guard rails in practice.
I would rather not have them than keeping unmaintained (very old) lower bounds on the minimal supported python version.

Let's wait for a definitive answer from the official nixpkgs python maintainers.

Yes, we want structural clean-up. However, I think everything beyond a single atomic commit per operation (remove obsolete pythonOlder, replace negated pythonOlder) would be too noisy.

And given that this is an operation we need to repeat, I think creating a script for the complete workflow would be the way to go.

I agree, making this repeatable seems very useful. Should be run whenever a python version is dropped.

creating a script for the complete workflow would be the way to go

what if there's multiple versions mentioned, translated from, say, ">=3.8,<3.12" (which is disabled = pythonOlder "3.8" || pythonAtLeast "3.12")?

I'd say the script should not worry about 100% perfection, but about doing the biggest chunk of work possible, and reliably and reviewable so. You can still grep for these kind of things and fix them manually.

For a script, also consider #427098, which introduces ast-grep support - I think this would be a perfect use-case for something like that. It's even possible to write tests for that script this way.

mkay then, I'll try to write a script and then remake this PR with it

#433233 (comment)

Nah, i lost motivation, sorry for bothering yall 🙏

I'm sorry to hear that