The design is only going to be future-proof if variants can be arbitrarily defined by package publishers.
It would be the responsibility of anyone defining a variant to provide a tool for determining the value of the selector value and setting that as a selection-time dependency for the target package.
I’ve proposed that selector values should be variables that can be used in the same expression syntax as requirements markers, and that we use that syntax for defining the rules for choosing a variant. There has been more exploration of using the tag system, instead, but I think the number of combinations of tags is going to make that untenable. Using tags also means that plugins modifying the list of tags supported by a system have to somehow cooperate for prioritization. Using variables and rules lets the package publisher provide that prioritization on a per-package basis, based on what they know about how they’ve built the wheels.
So, the PyTorch community might define a variant for “hardware_accelerator” and publish packages with “hardware_accelerator=cuda” and “hardware_accelerator=rocm” (these are over-simplified examples). They would then be responsible for building something that pip, uv, etc. could install (or require to be pre-installed) to answer “what is the value of ‘accelerator’ for the current environment?”.
We also know we have cases where the user needs to provide that value directly (lock files, build systems, etc.). When the value is provided directly, its value should override any discovered value (discovery could probably be skipped entirely, but it’s not clear if we can link the selector package requirement to specific variables).
Paul has expressed a desire that the tools be separate executables, and that they run in an isolated environment. I wonder if it would be easier if we required them to be pre-installed, and the installer exited with an error if it couldn’t find the tool? It’s less fully automatic, but maybe it’s an early version of the implementation?
Oscar’s original proposal had some more detail about how to prioritize for cases where multiple matches happen (as is the case with CUDA versions, for example).