SPLENT

From feature model to running product, in one command.

SPLENT is a Software Product Line Engineering Toolkit for Python. It bridges formal variability models with Docker, databases, and migrations — so every product you derive is validated, reproducible, and ready to run.

Read the docs See how it works
~/splent_workspace — zsh — splent
Built on Flask UVL feature model Docker-first LGPL v3 · open source DiversoLab · Universidad de Sevilla
Capabilities

Everything you need to run a product line.

SPLENT unifies the things that usually live in tribal knowledge — variability, composition, contracts, migrations — into a single, auditable pipeline.

Feature Lifecycle Management

Install, version, test, and release independent Python packages — each with routing, models, migrations, templates and assets built in.

Automated Composition

SPLENT merges Docker Compose definitions, environments and infrastructure across every feature — deterministically.

Formal Validation

UVL satisfiability checking, route collision detection, PyPI availability and contract compatibility — all before Docker starts.

Migration Ordering

Database migrations are applied in dependency order, so features compose safely no matter the installation sequence.

Multi-Environment

One pipeline, two targets. Development and production with health checks, port offsets and credential layering.

Comprehensive CLI

Commands for discovery, lifecycle, contracts, testing and deployment — the operator surface for your product line.

Three pieces, one system

An ecosystem designed to compose.

Framework, CLI and Cache work as a single toolkit. Each one is independent, but together they turn your variability model into a deployable product.

Runtime

SPLENT Framework

Feature discovery, composition, configuration layering and template resolution — inside Flask.

  • Blueprints, services, repositories, seeders
  • Signals, i18n, template hooks
  • Layered configuration
Operator

SPLENT CLI

Lifecycle, contracts, deployment and release automation. Your operator surface for the product line.

  • Discovery · Lifecycle · Contracts
  • Development · Release · Products
  • Database · SPL · Doctor
Storage

SPLENT Cache

Local, versioned feature storage. Read-only by design, so your workspace stays reproducible.

  • Pinned versions
  • Offline-friendly derivation
  • Source-of-truth lock
How it works

Model your variability.
Derive your product.

Describe features and constraints in UVL. Let SPLENT validate, compose and launch — one command, every environment.

splent.uvl
Feature model · source of truth 
features
    SplentApp
        mandatory
            Auth
                alternative
                    OAuth
                    Local
            Profile
        optional
            Notifications
            Analytics

constraints
    OAuth => Notifications
terminal
One pipeline · validate → sync → generate → launch 
# 1. Install features (pinned)
splent feature:install splent-io/splent_feature_auth --pinned
splent feature:install splent-io/splent_feature_profile --pinned

# 2. Derive the product
splent product:derive --dev

# ▸ UVL satisfiability: OK
# ▸ Contracts: OK
# ▸ docker-compose merged
# ▸ migrations applied in order
# ✓ running on http://localhost:5000
01

Validate

UVL satisfiability, contracts, PyPI availability, route collisions.

02

Compose

Merge docker-compose, environments, and infrastructure across features.

03

Launch

Run migrations in dependency order and start the product with health checks.

Why SPLENT

Variability shouldn't be a maintenance tax.

Most teams reach for duplication, feature flags, or microservices. SPLENT offers a fourth option — a variability model that drives the infrastructure.

The old trade-offs

  • Code duplication
    Forks per client turn into a maintenance nightmare. Every bug fix has to be re-applied across branches.
  • Feature-flag sprawl
    Conditionals grow everywhere. The real product behavior disappears into runtime toggles nobody fully tracks.
  • Microservice explosion
    Splitting every variation into its own service trades one problem for a distributed systems tax.

The SPLENT way

  • A formal model, not a folder of branches
    UVL defines features and constraints explicitly. The model is checked for satisfiability before a single container starts.
  • Composition is mechanical, not tribal
    Docker Compose, environments and migrations are merged by the toolkit — deterministic, auditable, reproducible.
  • One pipeline, every environment
    product:derive validates, composes and launches. Dev and prod share the same path. Problems surface before Docker.

Ship variability without the tax.

Read the documentation, clone the repositories, and derive your first product in minutes.

Read the docs View on GitHub