using environment variables

[iham]

New Feature Proposal

Using environment variables

Description

When environment variables are set, they should be picked by piral.

Background

Working with docker, docker compose or other orchestration tools, environment variables are a main option to change settings and behaviours on a containerised app.

piral debug . should be able to pick up those (like $PORT or other options) as set with environment variables and use them.

Discussion

Unpacking env variables to fit the argument/param style, based on being set or needed is hard to come by using shell scripting.

Pro: A piral container can become very flexible by using env vars.

Con: pirals configs would need to recognise process.env vars and use them. some code refactoring might be needed

[FlorianRappl]

Hm can you explain what exactly you want?

From the description I think you want to use environment variables to control the piral CLI, but this is already done (see the documentation) via the rc file and CLI flags (as such you could configure the port via piral debug --port $PORT).

If you want automagically to have such variables included you should make a proposal which variables you are missing (what should be their name, purpose). I think the current concept relying on the rc file and explicit arguments is much better and cleaner - specifically because there is no need for double documentation.

[iham]

yes, one can use environment variables to be passed as arguments as you mentioned.

I am looking into the direction of using environment variables without the need to pass them as arguments.

maybe I should explain further: Using docker (or docker compose) in order to containerise development and production typically gets flexible by using env vars for runtime settings. after building an image with a default piral instance I would like to pass runtime settings. like --port or --feed and any other you can set using argument.

docker run -e PORT=3000 -e FEED="a-domain-or-ip-or-local-address" <piral-intance-image> currently has to be translated to piral debug . --port $PORT --feed $FEED manually. Therefore I need to check and pass every possible env var to every possible arguments.

also as there are some arguments without defaults, so unused env vars need to be excluded. (I can't start piral using all arguments and env vars)

building an entrypoint.sh script to handle that is hard as well.

I thought it would be handy to have the ability to use env vars and start piral like this export PORT=3000 && piral debug or in the context of docker piral debug as the env vars are set already at startup.

piral-cli-dotenv (sort of) goes that direction, but afaik does not take care of default settings like PORT, FEED and others. I am unsure about that, but I guess dotenv it is exclusively using .env files and ignores env variables.

I guess there is a place to pick up env vars and pass them on: https://github.com/smapiot/piral/blob/a225faea9c8d36d92ac81066ebb40db97a65fd34/src/tooling/piral-cli/src/common/config.ts#L78-L99

to stay explicit on the arguments side of things: they should overrule env vars.

hopefully I didn't make it more complicated by trying to explain it ;)

[FlorianRappl]

Yeah but the Docker setup is not really something we want to encourage for multiple reasons:

1. Docker is not really ideal for development setups (there are better alternatives and supporting Docker here would mean we'd also need to support the alternatives directly)
2. For production you don't want to run the piral-cli, so your Docker container (if any) will not rely on the piral-cli

The example export PORT=3000 && piral debug looks better (and is more readable) like piral debug --port 3000 (with the first one you need to understand what the ENV does; which in case of PORT might be straight forward, but going beyond PORT it becomes a documentation mess quite easily).

So far I am not convinced, but maybe more people have a similar desire. In general though I guess we accept PRs in that direction.

[FlorianRappl]

My assumption right now is that this is not desired / not needed any more.

Let me know if that changes (or if a PR is available).