Implementation variants: rehashing and refocusing

[ncoghlan (Alyssa Coghlan)]

@brettcannon

@ncoghlan

I also think I see a way of defining Doug’s selector module idea less in terms of actual accessible-at-runtime importable code (which is what was making me most skeptical about the idea), and more as a declaration of “variant semantics for this module are taken from this other module” (which seems like a plausible way of distributing the semantic definition problem in a way that is manageable without requiring fully centralised decision making).

When do you see that code executing?

Short answer: that would be up to the authors of installation and locking tools that wanted to pick non-default variants without requiring them to be explicitly requested.

Longer answer:

I suspect there would be four main approaches to handling the variant selector logic modules:

• ignore them completely, only install non-default variants when explicitly requested (e.g. a basic installer that pushes the entire problem of selecting non-default variants off to locking tools would work this way)
• only check for known variant selection schemes in the explicitly declared dependencies (allowing them to be checked and the preferred variant order for the current platform determined before the main resolution process starts)
• allow checking for known variant selection schemes for all dependencies encountered during the dependency resolution process (whether those dependencies are explicitly declared direct dependencies or implicit transitive ones)
• don’t support dynamic variant selector code execution at all, and instead accept config information that specifies known variant selectors and the preferred variant order to be used when resolving (i.e. require the selector logic to be run externally to produce the config metadata for the resolver. Depending on the use case, the variant order might even just be specified directly by a human writing values into a config file). This would have two subvariants like the above (config consulted only for direct dependencies, or for both direct and transitive), and could also appear in a form where the static config complemented dynamic variant selection rather than replacing it entirely.

The first and last cases are the ones I’d consider most important to consider when defining the underlying metadata, as if those work, then the dynamic configuration can come later as a convenience feature rather than as an essential required component of the system design (potential standardisation of the variant selector runtime APIs would then come later still based on observation of common patterns across selector APIs, rather than needing to be specified up front).