feature:install

Introduction
Installing a release without prompts
Installing a copy you will edit
When it requires other features
What happens after it registers
Reference
Requirements
See also

Introduction

feature:install is the usual way to put a feature in your product. In one step it fetches the feature and what it requires, registers it, merges its environment variables and starts its own services.

splent feature:install splent-io/splent_feature_notes

  Install as (editable, pinned) [pinned]: pinned

  installing notes (pinned)
  version  fetching available versions...

    1)  v1.3.0 (latest)
    2)  v1.2.0

  Select version [1]: 1
  version  selected v1.3.0
  cache    notes@v1.3.0 already cached
  attach   notes@v1.3.0
  env      generate + merge

  notes installed.

Pinned mode clones a tag into the cache and attaches it. Editable mode clones to the workspace root and adds it.

Installing a release without prompts

splent feature:install splent-io/splent_feature_notes --pinned --version v1.3.0

--pinned skips the mode prompt and --version the version prompt. The tag is cloned into .splent_cache when it is not there, and feature:attach pins it. A tag that does not exist installs nothing.

Installing a copy you will edit

splent feature:install splent-io/splent_feature_notes --editable

The feature is cloned to the workspace root at its latest tag and switched to main, so you can commit and release. feature:add then links it. A feature already at the workspace root is installed as editable without asking.

--dev and --prod declare it in features_dev or features_prod. Without either, the env of the feature’s contract decides.

When it requires other features

  notes_tags requires features not installed in my_first_app:
    - notes

  Install them first? [Y/n]: y

The command reads [tool.splent.contract.requires].features and offers to install what your product lacks, each one with its own requirements. Requirements match by short name, in any of the three feature lists.

A missing feature comes from the namespace a product of your workspace declares it under. Failing that, from its copy in .splent_cache or at the workspace root, then splent-io.

What happens after it registers

The new variables reach the product’s environment through product:env --generate and --merge, for the current SPLENT_ENV. A feature with a compose file of its own gets its services started, and the product is not restarted.

The product’s forge workflows follow the new feature too. See Keeping the workflows in step.

Reference

Option	Description
`--pinned`	Pin a released version. The prompt lists the ten newest tags
`--editable`	Clone as an editable copy at the workspace root
`--version TEXT`	The version to pin, such as `v1.3.0`. Pinned mode only
`--dev`	Declare it in `features_dev`
`--prod`	Declare it in `features_prod`

Message	Exit	What to do
`<feature> has no version <version> on the forge`	1	Pick a tag `feature:versions` lists
`Could not clone <ns>/<feature> (tried SSH and HTTPS)`	1	Check your access to the forge
`Could not switch <short> to its main branch.`	0	Check out `main` before you commit
`Aborted.`	1	You declined to install its requirements
`Attach failed`, `Add failed`, `Env merge failed`	1	Read the error of that inner step
`Docker failed: ...`	0	The feature is installed. Start its services with `product:up`

Requirements

A selected product (SPLENT_APP). SPLENT_ENV, dev by default, picks the environment for the env merge and the services.
Access to the forge, unless the release is already in .splent_cache.