The configurator
Pick a product line, select features with live variability validation,
and walk away with the exact splent commands that build your product.
Table of contents
The flow
- Choose a product line. The chooser lists every SPL in the marketplace index that carries a parsed UVL model.
- Select features. The configuration page renders the model as mandatory features, optional features and alternative groups.
- Validate live. Every change re-validates the selection against the variability model and updates the result, valid or not, and why.
- Copy the commands. A valid selection produces a copyable block of
splentcommands that create and derive the product.
What the page enforces
| Rule | Behaviour |
|---|---|
| Mandatory features | Pre-selected and locked. They are part of every product of the line and cannot be deselected. |
Requires-constraints (a => b) |
Applied transitively. Selecting a auto-adds b (and whatever b implies). Auto-added features are marked with an amber badge so you always see what the model added for you, and why your product is bigger than your click count. |
| Alternative groups | At most one member may be selected (e.g. one session backend). A group whose members are mandatory must have exactly one selection. Leaving it empty is a violation. |
Violations are structured and explained in plain language next to the
selection (an unknown feature, two members of an alternative group, or
a required group left empty), so fixing the configuration never requires
reading UVL.
The command block
A valid configuration ends in the exact command sequence, ready to copy.
splent product:create my_app --spl marketplace_spl
splent product:select my_app
splent feature:add splent-io/splent_feature_theme
splent feature:add splent-io/splent_feature_auth
...
splent product:resolve
splent product:derive --dev
Nothing is executed on your behalf and no account is involved. The configurator’s only output is commands you run in your own workspace.
Scope of the validation
The configurator validates with its own logic over the index’s parsed
model, covering mandatory presence, the transitive closure of a => b
constraints, and alternative group rules. It deliberately does not
embed a SAT solver. Flamapy-based analysis stays in the CLI
(product:validate, spl:* commands) and in
UVLHub, where the full .uvl files live.
This keeps the web app dependency-free and instant, at the cost of known limits.
- Only simple implications (
a => b) are understood; arbitrary cross-tree formulas in the UVL are not evaluated here. - No cardinality or numeric constraints.
- The model it sees is the index’s parsed snapshot, not the live
.uvl.
The generated command sequence ends in product:resolve /
product:derive, which re-validate the configuration against the real
UVL model, so the CLI remains the final authority.