product:env
Table of contents
- Introduction
- Creating the env file
- Merging the features into it
- Merging for production
- Values the shell would misread are quoted
- Reference
- Requirements
Introduction
product:env writes your product’s .env for one environment. --generate creates it from the product’s template, and --merge rebuilds it with the variables of every feature. product:derive runs both for you.
splent product:env --generate --all --dev
splent product:env --merge --dev
product .env created from .env.dev.example
...
declared 3 default(s) from feature pyprojects
ports adjusted 1 feature port(s) (+591)
merged 4 feature .env file(s) into product .env
Creating the env file
splent product:env --generate --dev
This copies docker/.env.<env>.example, or docker/.env.example, to docker/.env. An existing docker/.env is left alone.
Add --all to also create the env file of every declared feature, as splent feature:env <feature> --generate does. When one fails, the command prints <n> created, <m> failed and exits 1, so product:derive stops.
Merging the features into it
splent product:env --merge --dev
The merge rebuilds the file from these layers.
The features add the variables your template does not have. Their port variables are shifted by the product’s port offset. Then [tool.splent.config] of the features and of the product apply, and the CLI sets SPLENT_ENV and SPLENT_NETWORK.
The merge starts from the template, so a value you edited by hand in docker/.env is replaced. Change the template or [tool.splent.config] instead.
A key a feature declares in its [tool.splent.config_schema] is checked against it. A value the schema refuses stops the merge, naming the key and the file, and so does a table no schema declares.
Merging for production
splent product:env --merge --prod
With --prod the merge writes deploy/.env, the settings of the deploy bundle. It never touches the development docker/.env.
Every value you set in deploy/.env is kept, and a value you never touched follows the template, as product:deploy does (see How deploy/.env is kept). The previous file is saved as deploy/.env.bak, and the files are written with mode 0600.
The optional production settings the file does not set, such as GUNICORN_WORKERS or SPLENT_TRUSTED_PROXIES, are appended commented out with their explanation (see Environment files). A secret written as <SET> stays <SET> until you fill it in.
Values the shell would misread are quoted
ABOUT_NAV_LABEL="Quiénes somos"
AUTODEPLOY_SECRET="<SET>"
A value with whitespace, #, a quote at either end, or a character the shell reads as syntax (<, >, |, &, ;, ( or )) is written double-quoted. Unquoted, a shell sourcing the file would drop every variable after that line, and product:restart sources it with bash. Docker Compose and python-dotenv strip the quotes as the shell does, and plain values stay bare.
Inside the quotes, backslashes and double quotes are escaped, so a value survives any number of rewrites.
Reference
Options
| Option | Description |
|---|---|
--generate |
Create docker/.env from the template, when it does not exist |
--all |
With --generate, also create the env file of every declared feature |
--merge |
Rebuild the env file from the template and the features |
--dev, --prod |
The environment. One is required |
One of --generate and --merge is required.
Errors
| Message | What to do |
|---|---|
product no .env template found in <dir> |
Add docker/.env.<env>.example. Nothing was created |
No .env template found for <product> (<env>) |
The merge has no template and no .env to start from |
pyproject.toml not found at <path> |
Run it on a product |
You must specify --dev or --prod. |
Pass one |
Requirements
- A selected product (
SPLENT_APP) withpyproject.tomland adocker/directory.