Implementations

Two complementary surfaces live on this ornament: a typed-spec layer and a consumer-coordination layer.

Typed-spec layer

A define call describes a project that supports multiple interchangeable implementations under a single langName. Each ImplementationDescriptor carries a name and an open capabilities attrset for impl-specific metadata (e.g. invocation flags, version range, supported targets).

select spec implName returns the descriptor or throws if absent. available spec excluded filters out broken/excluded impls. perImpl spec f evaluates f against each impl and returns the results keyed by impl name — the typed analog of dynamic .${implName} projections.

Consumer-coordination layer

defineSystem { langName; implementations; defaultImpl; makeOverridable; allowUserExtensions ? false } returns { impls; withExtras; filterByName } (plus extend when extensions are allowed). The implementations argument is an attrset ({ impl-a = {...}; impl-b = {...}; ... }) so consumers can produce the coordination record without re-shaping input.

withExtras builderFunction args projects per-impl variants under result.${implName} attributes, injects passthru.repl when an impl exposes replWith, and populates passthru.meta.ci.targets with the implementations minus the current one and brokenOn.

filterByName impl xs resolves implementation-specific sources/dependencies — plain values pass through; non-derivation attrsets are treated as per-impl selectors with optional default.

makeBuilder { implsSystem; createPublicAPI; baseToolEnv } recursively wraps a createPublicAPI projection with extend and withTools so downstream consumers receive the full builder surface (not just an impls-system) after extension or tool augmentation. Cross-ornament dependency on mb.ornaments.toolEnv.