The issue with variant enumeration is that it is easy to get incomplete enumerations (which is one of the reasons we removed it from the core kernel logic). The (purely) informative enumeration #423 again suffers from this issue, because it does not take into account that we also support falling back to older CUDA versions. Similar issues may rise when we support compatibility with older ABI versions (e.g. Torch stable ABI?).
I think that we should instead focus on the possibility to provide an explanation why existing variants are rejected. This does not only suffer from the incomplete enumeration issue (and maintaining both compatibility checking and enumeration code paths), but is also more informative, because it makes it clear _why* none of the available variants can be used (which could guide the user towards e.g. using a different Torch version).
The issue with variant enumeration is that it is easy to get incomplete enumerations (which is one of the reasons we removed it from the core kernel logic). The (purely) informative enumeration #423 again suffers from this issue, because it does not take into account that we also support falling back to older CUDA versions. Similar issues may rise when we support compatibility with older ABI versions (e.g. Torch stable ABI?).
I think that we should instead focus on the possibility to provide an explanation why existing variants are rejected. This does not only suffer from the incomplete enumeration issue (and maintaining both compatibility checking and enumeration code paths), but is also more informative, because it makes it clear _why* none of the available variants can be used (which could guide the user towards e.g. using a different Torch version).