Support ENV

[chevdor]

Loading the ENV to the Tera context is convenient in 2 locations:

template

The template.toml itself could go thru a first transformation pass. That would allow for instance:

...
[[variables]]
name = "greeting_recipient"
default = {{ LOGNAME }}
prompt = "Who am I greeting?"

or something richer such as:

...
[[variables]]
name = "greeting_recipient"
default = {%- if LOGNAME %}{{ LOGNAME }}{% else %}Vincent{% endif%}
prompt = "Who am I greeting?"

scaffolding

I could imagine templates that can be controlled by ENV. For instance, calling MY_MODE=prod kickstart --env . would generate a diferent output than MY_MODE=dev kickstart --env .. What happens exactly is left to the template.

I would suggest NOT loading the ENV by default for security reasons. I would also suggest supporting a --env-key some_key or similarly named option that loads the ENV under the some_key key. Not only it allows accessing the ENV as a key/value but it also allows escaping potential collisions where both your template and your ENV could have a greeting_recipient (for instance).

[chevdor]

This could also help #45 as the user could run a script to populate the ENV before running kickstart:

VAL1=$(curl ....)
VAL2=$(curl ....)
kickstart --env .  # and use {{ VAL1 }} and {{ VAL2 }} in the templates

[chevdor]

Same for #42 :) Supporting ENV makes it much more generic than specific implementations.

[Keats]

I don't think it makes sense. Why would you have values for the project in your environment? Especially since as you said you wouldn't load them by default.

[chevdor]

You probably don't "have them" but the benefit here is that the user can create them before running kickstart.

I see many issues such as:

• #42
• #45

Instead of those, you can let the user do whatever python, shell, curl etc... call and store the result in an ENV that is then passed to kickstart.

Similarly to RUST_BACKTRACE=1 foobar, that would also allow generating multiple scaffolds from a single template.

If your question is: "Why should we use ENV vs the interactive input", the answer that anything automated such as CI will benefit from using ENV.

[Keats]

But 42 and 45 wouldn't be loaded from env. A file can kind of make sense but env I just don't see it - why would you use kickstart in CI? The usecase is to be used by humans. I'll leave it open but it's unlikely to happen.

[chevdor]

why would you use kickstart in CI?

to test and check your templates for a start !

Support for files and ENV definitely overlap. In general, most of what you can do with files can be done with ENV and vice-versa. Security practises however recommend using ENV.

Say for instance that a template needs to store a token into an .env file. You probably do NOT want to use a file input for the secret. The remaining options are:

• interactive as currently available
• ENV

Additionnally, there are lots of ENV that are already set that could be used as default values so the user does not have to -once again- provide his/her name:

• LOGNAME / USER
• HOME
• EDITOR
• PWD

I see that we have 2 topics actually:

• load the ENV before starting the interaction with the user to prefill some values
• load ENV when running the transformations, making the ENV available in the templates