SPLENT

From feature model to running product — in one command.

What is SPLENT

SPLENT — Software Product Line Engineering Toolkit — is a framework for building modular web applications in Python using Software Product Line (SPL) principles. It connects a formal variability model (what features exist and how they can be combined) with executable infrastructure (Docker containers, databases, migrations, deployments) — so that deriving a product from a feature selection is automated, validated, and reproducible.

A product in SPLENT is a thin shell that declares which features it includes. Each feature is an independently versioned Python package with its own routes, models, migrations, templates, assets, tests, and optional infrastructure (Redis, Nginx, mail, etc.). SPLENT handles composition, validation, and deployment.

The problem

Building software that must exist in multiple variants (different clients, plans, or research configurations) forces teams into one of three paths:

Copy and diverge. Fork the codebase per variant. Changes drift. Bugs get fixed in one fork but not the others.
Feature flags everywhere. One codebase, hundreds of conditionals. Every deploy ships everything. Testing the matrix is impractical.
Microservices. Each capability is a service. Operational complexity explodes — each service needs its own pipeline, database, deploy, and monitoring.

SPL research solves the variability problem formally (feature models, UVL, constraint satisfaction), but stops at the model. DevOps tooling solves the deployment problem practically (Docker, CI/CD), but treats the application as a monolith.

SPLENT connects both worlds: the variability model drives the infrastructure.

How it works

# Install features into the product (clone, register, env merge)
splent feature:install splent-io/splent_feature_auth --pinned
splent feature:install splent-io/splent_feature_profile --pinned

# Validate, build, and launch — one command
splent product:derive --dev

product:derive runs a full pipeline:

Validates the feature selection against the UVL model (satisfiability) and feature contracts (no route or model collisions).
Syncs all declared features from the cache or PyPI.
Generates environment files and merges Docker Compose definitions from all features.
Starts containers, applies database migrations in dependency order, and launches the application.

For production:

splent product:derive --prod

This builds a multi-stage Docker image, merges feature infrastructure into a single deploy-ready compose file, and launches production containers — with health checks, pinned image versions, and credential prompts.

What SPLENT validates before anything runs

Every product:derive and product:build runs pre-flight checks:

Phase	What it catches
pyproject sanity	Duplicate features, inconsistent namespaces, missing SPL catalog
UVL satisfiability	Mandatory features missing, unsatisfied constraints, invalid combinations
Contract compatibility	Route collisions, blueprint name conflicts, missing dependencies
PyPI availability (build only)	Unversioned features, packages not published

Problems are caught before Docker starts — not after a failed deploy.

Components

** SPLENT Framework ** The runtime core. Discovers, composes, and orchestrates features inside a Flask application. Handles configuration layering, template resolution, per-feature migration tracking, and production fallback to PyPI-installed packages.

** SPLENT CLI ** The command-line interface. Manages the full lifecycle: feature scaffolding, versioning, cache management, Docker orchestration, database migrations, testing (unit / integration / functional / e2e / load), and deployment to development and production environments.

SPLENT Cache Local storage for pinned feature versions, organised by namespace. Read-only by design — editable features live at the workspace root.

Sources of truth

SPLENT keeps configuration minimal and centralised. Four artefacts define the full state of a product:

Source	What it governs
`pyproject.toml`	Identity, versions, feature list, contracts
UVL feature model	Variability structure, constraints between features (lives in `splent_catalog/`)
`splent.manifest.json`	Lifecycle state of every feature
Environment files	Runtime configuration: hostnames, ports, credentials

The first three define what a product is. Environment files define how it runs.

Project

SPLENT is developed by DiversoLab at the University of Seville.

Repositories: splent_cli · splent_framework · splent_docs