I agree with this. What happens if the user installs both python_flint_x86_64_v3-0.6.0-cp312-cp312-win_amd64.whl and python_flint_x86_64_v4-0.6.0-cp312-cp312-win_amd64.whl? The two are different projects, so there’s nothing in the current ecosystem that would stop that.
In principle, I like the idea of the selectors just being custom markers, but we need to work within current semantics.
I haven’t thought this idea through (and I don’t have the time to right now) but could we use wheel build numbers to handle this?
python_flint-0.6.0-1.x86_64_v4-cp312-cp312-win_amd64.whl
python_flint-0.6.0-1.x86_64_v3-cp312-cp312-win_amd64.whl
These are both wheels for python_flint version 0.6.0. They sort based on (<integer prefix of build number>, <string rest of build number>). This allows the project to control priority. That just leaves the selection question. Maybe we could add a new metadata item, similar to Python-Requires in that it gets exposed in the simple API (we might even be able to simply add a marker expression to Python-Requires itself). Then, the installer evaluates the marker for each wheel and rejects any where the marker doesn’t return True.
The user still needs to install something that exposes the additional custom markers. Evaluating a marker expression with an unknown marker will fail, and the user needs to ensure the appropriate marker plugins are installed. Making that user friendly is “simply” a matter of good UI, though, it’s not a standardisation problem.