Is your feature request related to a problem? Please describe.
in projects, there are often different environments for dev, staging and prod for example. By environment I mean a collection of env vars that together represent the settings to run a program on a machine.
There are various reasons why different environments should be available on local . (you might want to connect to the staging database instead of your local dev one...).
env vars also raise the concern of committing secrets to the repo
Describe the solution you'd like
The first step I think is to be able to name a collection of env vars. staging, dev and production would be example of such collections.
Being able to merge collections would be great too. You could have a collection for common, and then specifics for each of the environment, then you would just merge the common with the specifics to get the full environment.
Having a command to be able to switch easily between different environments would be amazing. There could be a default environment, but with a command, I would just switch to staging and continue my manipulations there.
Being able to integrate with something like agenix would be amazing to prevent leaking secrets to the whole team. Incidentally agenix has a mechanism to handle different groups of users.
Describe alternatives you've considered
the alternative is to maintain several .env files and use dotenv-cli to generate environments for each commands. You can use a command to generate the proper environment. You don't commit the .env files you create since they contain secrets. But this workflow works at the moment.
Additional context
I think most teams need a workflow with different environments, but I'd be happy to describe in more details any part of the process that seems foreign.
PS: thanks again for taking the time to make this project. I've been using this shell everywhere since as long as I've known it.
Is your feature request related to a problem? Please describe.
in projects, there are often different environments for dev, staging and prod for example. By environment I mean a collection of env vars that together represent the settings to run a program on a machine. There are various reasons why different environments should be available on local . (you might want to connect to the staging database instead of your local dev one...). env vars also raise the concern of committing secrets to the repo
Describe the solution you'd like
the alternative is to maintain several
.envfiles and usedotenv-clito generate environments for each commands. You can use acommandto generate the proper environment. You don't commit the .env files you create since they contain secrets. But this workflow works at the moment.Additional context
I think most teams need a workflow with different environments, but I'd be happy to describe in more details any part of the process that seems foreign.
PS: thanks again for taking the time to make this project. I've been using this shell everywhere since as long as I've known it.