Your first product

Create a product from a Software Product Line, configure its features, and launch it in the browser.

Prerequisites
Step 1. Browse the SPL catalog
Step 2. Create the product
Step 3. Select the product
Step 4. Configure features
Step 5. Resolve features
Step 6. Derive and launch the product
Step 7. Seed the database
Step 8. Open the browser
Step 9. Stop the product
What you learned
Next

Prerequisites

You have completed Getting started and are inside the CLI container.

(detached) /workspace$

If not, enter the container now.

cd splent_cli
make cli

Step 1. Browse the SPL catalog

splent spl:list

You will see at least one entry, sample_splent_spl.

An SPL (Software Product Line) is a reusable feature model that defines which features exist, which are mandatory, which are optional, and how they depend on each other. Think of it as a blueprint for an entire family of applications.

Step 2. Create the product

splent product:create my_first_app

If more than one SPL exists in the catalog, the command prompts you to pick one (Select SPL [1]:); with a single SPL just press Enter to accept the default.

SPLENT generates a full project directory at /workspace/my_first_app/ containing the following.

pyproject.toml. Project metadata and feature declarations
src/. The Flask application factory (src/my_first_app/)
scripts/. Numbered startup scripts (install deps, migrate DB, run server)
docker/. Dockerfiles and Compose files for dev and prod
entrypoints/. Shell entrypoints for dev and prod containers

product:create only scaffolds. It does not build or run anything. At this point you have an empty project skeleton with no features selected, no dependencies installed, no database, and no containers. It is not a runnable product yet. The product only becomes a working application after you select it (Step 3), configure its features (Step 4), resolve them (Step 5) and finally derive it (Step 6). product:derive is the command that actually builds the images, sets up the database and launches the server.

Step 3. Select the product

splent product:select my_first_app

The prompt changes to show the active product.

(my_first_app) /workspace$

From now on, every splent command targets this product.

Step 4. Configure features

splent product:configure

An interactive selector walks the SPL feature tree. Mandatory features are pre-selected and cannot be removed, namely auth, public, and the session_type group. session_type is an alternative group, so you must pick exactly one session backend.

session_redis. Server-side session storage with Redis (requires redis)
session_filesystem. File-based session storage

Then it prompts the optional features one by one (answer y/N).

redis. Redis cache backend
mail. Email sending infrastructure
confirmemail. Email verification (requires mail and auth)
profile. User profile management
reset. Password reset (requires mail and auth)
admin. Admin panel (requires auth)
mailhog. Local email testing server (dev only)
phpmyadmin. Database admin UI (dev only)
nginx. Reverse proxy

For this tutorial, at the session_type prompt pick session_redis (option 1). Picking it auto-selects redis (its dependency), so redis is never prompted as an optional. Among the optionals you only enable profile (answer N to the rest). Together with the mandatory auth and public, that gives you auth, public, redis, session_redis, profile.

Watch what happens. When you pick session_redis, the configurator already knows it requires redis and auto-selects it, so redis then shows as auto-selected by dependency. The same happens with profile => auth. These constraints come from the UVL model in the SPL catalog. If you tried to select confirmemail without mail, the validator would reject it.

After confirming, SPLENT writes the selection to pyproject.toml and validates the configuration against the SPL constraints.

Step 5. Resolve features

splent product:resolve

This creates the features/ symlink directory inside the product and links each feature to its location (workspace root for editable, .splent_cache/ for pinned). After this step, the product has all its dependencies resolved and ready for the build.

Network step. Pinned features are cloned from GitHub into .splent_cache/ the first time they are resolved, so this can take a little while on the first run and needs network access. Already-cached versions resolve instantly.

Step 6. Derive and launch the product

splent product:derive --dev

Heavy step. This can take several minutes. product:derive builds the web and database Docker images, installs every feature, runs migrations and starts the server. On a first run (cold Docker cache, images to download) expect a long wait; later runs are much faster thanks to layer caching. If the terminal seems stuck mid-build, it is still working, so let it finish.

This is the main build command. It performs several steps.

Infrastructure check. Validates Docker port and service declarations
Dependency resolution. Resolves feature order from UVL constraints
Docker build. Builds the web and database containers
Feature installation. Clones pinned features into .splent_cache/ and creates symlinks
Database setup. Creates the database schema and runs migrations in UVL order
Server start. Launches Flask with auto-reload enabled

The terminal prints the URL when the server is ready (typically http://localhost:5591).

Step 7. Seed the database

splent db:seed -y

This populates the database with initial data (test users, sample content) provided by each feature’s seeders. Without this step, the database is empty and you cannot log in.

Step 8. Open the browser

Navigate to the URL printed in the terminal. You will see the login page provided by splent_feature_auth. Log in with the seeded test user.

Email is user1@example.com
Password is 1234

The authentication system, public pages, session management, and profile editing are all working, composed from independent features.

Step 9. Stop the product

splent product:down --dev

This stops all Docker containers for the product.

What you learned

Concept	Summary
SPL	A reusable feature model that defines features and their constraints
Product	A concrete application derived from an SPL with a specific feature selection
Configure	Interactive selection of features with automatic constraint propagation
Derive	End-to-end build (infrastructure, dependencies, database, server)

Continue with Tutorial 2, Exploring your product, to learn the inspection tools that show you exactly how your product is composed.