Investigate strategy for setting environment variables about andculturecode.cli HOT 4 OPEN

Note: Ensure forwarding of environment variables is done in a cross-platform manner (ie. cross-env)

from andculturecode.cli.

While I can see the explicit command param useful, the integration of dotenv will eventually occur which will allow for project-level, developer/local/etc..., environment specific config files that pre-load environment variables. I'm totally cool if we do both. Merely saying to consider if we feel dotenv will be as good/if not better for folks use cases, perhaps we consider doing that first?

from andculturecode.cli.

That's a good point. How do you think that should work? Would it automatically look for *.env file(s) in the current directory and decide which one it should use based on an existing environment variable? (such as ASPNETCORE_ENVIRONMENT=Development would load development.env)

from andculturecode.cli.

Totally up for discussion, but here are some initial thoughts on functionality based on how I've used .env files on varying projects...

CLI environment "install [?template]" comand

• would generate a template .env file in your current directory based on .env.sample shipped with and-cli itself
• would add exclude to project .gitignore of .env so it doesn't get checked in. common pattern is for team to check in .env.{template} with safe key=value defaults to ease configuration. But any sensitive ones are managed with other means (password lockers, etc...)

CLI environment "switch [template]" command

• simply takes a template (if it exists) of .env.{template} and overwrites .env with it.
• bonus feature could be interactive mode: when switching, it parses the file and anywhere there isn't a default value (key=), it asks a question. If that variable has a comment above it, it would pipe that into the prompt as well.

CLI leveraging of .env files

• CLI would load .env file found in project directory (indicated by .git directory)
• The project team could keep as many .env.{xyz} named files in the repo checked in to serve as merely a template. From there if they want to use one they cp .env.{desired-version} .env.

Should we have .env file inheritance?
While dotnet core added this ability to inherit variables through different levels of config (reminiscent of web.config transforms), I honestly feel it lends to mismanagement and confusion. I feel it would probably be best to all be one flat version of properties.

The maintainers for dotenv weigh in on this as well...

Should I have multiple .env files?
No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

– The Twelve-Factor App

from andculturecode.cli.