Interface to builtin providers #143

The providers PEP introduces a concept of builtin providers: in the narrow sense, the abi_dependency provider that allows building variants of a package against different version ranges of its dependencies; in the wide sense, any special PEP-defined provider. This opens up the question of how to integrate it with variantlib.

The absolutely minimal approach taken in #142 only ensures that variantlib can recognize and expose the metadata. At the same time, it makes all the relevant API functions raise an exception if a builtin provider would need to be used.

I've been thinking how we could extend the logic to builtin providers. We could either implement them inside variantlib (if possible) or provide hooks to let tools pass their own implementation to variantlib.

For the abi_dependency provider, there is certain asymmetry involved.

When building wheels, we need to verify whether the properties are valid. Depending on how detailed we want this check to be, we could either check if they're well-formed package names and version, or we could go further and verify whether a matching package version is installed in the build environment. If we go for the latter, the tools would probably need to be able to override the check. Either way, this could be entirely implemented within variantlib.

When installing wheels, we need to select a variant matching other packages in the dependency graph. To be honest, I don't know what kind of hook we could provide for that. In the end, our API may be insufficient, as it operates on a single package, whereas here you need to simultaneously be able to find a matching variant over multiple packages.

My current idea of a reasonably flexible approach would be to introduce a class like "dynamic plugins" of the past, and defer builtin provider work to that. The API functions would take an optional dictionary with builtin providers like:

builtin_providers={"abi_dependency": MyABIDependencyProvider}

An example class would implement verifying variant description for the purpose of building wheels (i.e. validate_variant()) and would raise NotImplementedError for get_variants_by_priority(). We could even provide such a minimal class for tools to reuse.

I suppose for a full resolution, the installer would need to process the abi_dependency properties separately and pass already-filtered properties down to variantlib.