product:select

Table of contents

1. Introduction
2. Selecting from a script
3. Another product for one command
   1. What stays with the selected product
   2. A second product, from scratch
4. Errors
5. Reference
6. See also

---

Introduction

product:select sets the active product. Every command that works on a product, from features to containers, uses it from then on.

splent product:select my_first_app

It writes SPLENT_APP=my_first_app to the workspace .env and prints nothing.

---

Selecting from a script

eval "$(splent product:select my_first_app --shell)"

--shell also prints export SPLENT_APP=<name>, so a script or a prompt can eval it. The workspace .env is written either way.

---

Another product for one command

Selecting changes the product of every command, agent and release gate of the workspace at once. To work on a second product without that, give the product to the command itself.

SPLENT_APP=my_other_product splent product:validate

Nothing is written to .env, so every other command keeps the selected product. Every command finds its product by the same rule.

1. The command’s own option, where it has one, as in product:test --product and product:release --product.
2. SPLENT_APP in the command’s environment.
3. SPLENT_APP in the workspace .env.

An empty SPLENT_APP= runs one command detached, as in SPLENT_APP= splent spl:list. unset SPLENT_APP does not, because then the .env decides.

If your shell loads the workspace .env first, put the override after it.

set -a && . ./.env && set +a && SPLENT_APP=my_other_product splent product:validate

What stays with the selected product

The CLI’s container stays on the selected product’s network. So a command on another product that needs its services or builds its app runs in that product’s web container, <product>_web. That covers db:*, a feature’s own commands such as feature:notes export-notes, and product:routes, product:config, product:signals and product:console.

Start the other product first, with product:up --dev or product:derive --dev and the same override.

db:migrate run there writes the migration unformatted, because the product’s image has no ruff. Run ruff format on it from the CLI.

A second product, from scratch

splent product:create my_other_product --spl my_spl --no-select
SPLENT_APP=my_other_product splent product:configure
SPLENT_APP=my_other_product splent product:validate
SPLENT_APP=my_other_product splent product:derive --dev
SPLENT_APP=my_other_product splent product:port
splent product:test --product my_other_product

product:create --no-select creates it while another product is selected. Its ports come from its own name (port offset), so both products run at once, each on its own network.

---

Errors

The name must be a product folder of the workspace, in lowercase letters, digits and underscores, with a pyproject.toml that has a [tool.splent] table. Otherwise the command exits 1.

Error: '<name>' is not a product name. Give the name of a product folder in <workspace> (lowercase letters, digits and underscores).
Error: product '<name>' not found in <workspace>
Error: '<name>' is not a SPLENT product: <name>/pyproject.toml has no [tool.splent] table.

A SPLENT_APP that is a path, for example one written by hand into .env, is refused by every command that uses the active product.

  SPLENT_APP is a path, not a product name: '<value>'.
  Run: splent product:select <name>

---

Reference

Option	Description
--shell	Also print export SPLENT_APP=<name> for eval

See also

• product:deselect enters detached mode.
• product:list lists the products you can select.