[Plugin API / optional] API to get suggested `requires` and `enable-if` values

[mgorny]

Currently, when adding a new provider to pyproject.toml, the user has to manually find the correct values for requires and enable-if (in variantlib, we "guess" the former but it's largely imperfect).

I'm thinking it could be helpful to add an optional API that would return the suggested values for requires and enable-if. So for example, if your plugin uses SemVer, it would return a package dependency with >={version},<{next version} restriction. And say, an x86-64 provider could suggest an enable-if restricting it to the systems using this architecture.

[rgommers]

This feels a bit unnecessary to me. The problem isn't really different from PEP 517 boilerplate; it's two lines and you look them up in the docs of the build backend once. Same here, copy-pasting two lines from the plugin's docs doesn't seem cumbersome enough to be adding an extra API for. And most users wouldn't know about this API existing anyway, so they'd get it from the docs.

Now a plugin is free to add API surface outside of the spec so nothing is prohibiting adding something like this in the future if it turns out to solve a point of friction. But I wouldn't add it now.

[mgorny]

Hmm, you're probably right.

[konstin]

Another option is that plugins aim to be universal: A provider would not just cover x86_64 levels, but all CPU features, and another plugin wouldn't just cover CUDA, but all accelerators. Different packages in your dependency tree will provide different levels of support, for example more packages will provide x86_64 variants than NEON support, and there are many linux-only CUDA packages, but (for static plugins), you would run them once for the whole tree (the first time you encounter them), and it's fine if they don't use enable-if.

The counterpoint is that it's best practice to only declare dependencies you actually need, so enabled-if should be scoped to the platforms you provide variants for.

[mgorny]

In general having enable-if is not obligatory — plugins definitely should work (as in return no supported configs) on these systems. But yes, the point was to avoid installing unnecessary dependencies.

As for having a single plugin for multiple systems, I have mixed feelings about it. Sometimes it will work, sometimes it could cause governance problems. I can imagine nVidia wanting to maintain CUDA plugin, but not wanting to maintain ROCm support, and the other way around. For CPUs perhaps it's easier, but we still may run into governance problems.

[konstin]

In uv, we already have a --torch-backend option supporting CUDA, ROCm and XPU, that we detect and support, and for detecting CPU features there are existing libraries, such as https://github.com/RustCrypto/utils/tree/master/cpufeatures. A generic GPU provider could also be a small shim over vendor libraries.

[mgorny]

Still, I don't think it really solves the governance problem. Perhaps the security discussion would result in a different approach, but right now we don't really want to control how people develop plugins.

To repeat another problem posed by @DEKHTIARJonathan earlier: who would decide whether CUDA or ROCm has higher priority? Right now we're working around the problem by not having global priorities between providers and letting package maintainers take care of that. Within plugin, however, things need to be ordered somehow — so inevitably one vendor will have to go first.

[konstin]

I'm not aware of users that have a single machine with both CUDA and ROCm hardware, so any order will do as we select for the installed GPU.