spoonbill

Seems like you do have an interest in Wayland, if it informs your choice of DE. Most users have no intetest in it, so they don't care whether it's there or not.

Yet another alternative is jsonata.org

From what I gather, the licence is still in the spirit of open source

It's not though. It's wildly against it. The spirit of open source is that anyone can take open source code and use and modify it. This isn't the case here.

Windows 7 does not receive security updates anymore, so its use should definitely be discouraged even if it "works".

For software devs, they almost certainly don't want to support an obsolete OS with a small number of users, as that requires time and effort on their side (e.g. if a user has problems on Windows 7 what should they do?). And if they want to refactor some code, do they really want to test on ancient OSs and add needed workarounds / compatibility fixes?

Here is another prediction: the volume of that bet would be nowhere near where it needs to be to make the bet interesting.

Disagree? Create the bet yourself and prove me wrong.

If most people prefer pyproject.toml over requirements.txt, even if it does not support everything you need, isn't it more likely that you will have to change workflow rather than python remaining stuck with requirement.txt?

I was asking why you need to have a centralized pyproject.toml file, which is apparently why you need constraint files? Most people don't have this workflow, so are not even aware of constraint files, much less see them as a must-have.

Why do you need to have a centralized pyproject.toml?

My only use case so far has been fixing broken builds when a package has build-)ldependencies that don't actually work (e.g. a dependency of a dependency breaks stuff). Not super common, but it happens.

But pyproject.toml supports neither locking nor constraints.

Constraints are useful for restricting build dependencies of your dependencies, especially if they follow PEP-518.

What do you mean by "screen grab"?