Easily switch between predefined values for arbitrary environment variables Features include (but are not limited to):
```toml
[apps.server] dev = {SERVICE1 = "dev", SERVICE2 = "also-dev"} prd = {SERVICE1 = "prd", SERVICE2 = "also-prd"} ```
```sh
es server | source ❯ === dev === SERVICE1=dev SERVICE2=also-dev
=== prd === SERVICE1=prd SERVICE2=also-prd
echo $SERVICE1 $SERVICE2 dev also-dev ```
(See the disclaimer for why piping to source is needed)
env-select operates with a few different buildings blocks:
A variable mapping an environment variable with a value. A key and a value. Variables can either be selected independently (via the vars key in the config) or be part of a profile with other variables.
sh
SERVICE1=dev
A profile is a set of variable mappings.
sh
SERVICE1=dev
SERVICE2=also-dev
An application is a group. "Application" in this case is a synonym for "use case" or "purpose". Each profile in an application accomplishes different versions of the same goal.
```sh
SERVICE1=dev SERVICE2=also-dev
SERVICE1=prd SERVICE2=also-prd ```
First, define .env-select.toml. This is where you'll specify possible options for each variable. Here's an example:
```toml [vars] TEST_VARIABLE = ["abc", "def"]
[apps.server] dev = {SERVICE1 = "dev", SERVICE2 = "also-dev"} prd = {SERVICE1 = "prd", SERVICE2 = "also-prd"}
[apps.db] dev = {DATABASE = "dev", DBUSER = "root", DBPASSWORD = "badpw"} stg = {DATABASE = "stg", DBUSER = "root", DBPASSWORD = "goodpw"} prd = {DATABASE = "prd", DBUSER = "root", DBPASSWORD = "greatpw"} ```
Now, you can easily switch between the defined values with es.
We can select between multiple values for a single variable, in this case TEST_VARIABLE. This is a shorthand for defining an application with multiple single-variable profiles.
```sh
es TESTVARIABLE | source TESTVARIABLE=abc ❯ TESTVARIABLE=def echo $TESTVARIABLE def ```
In the config above, we've already predefined an application called server, which consists of two profiles, dev and prd. We can select between those profiles by providing the application name.
```sh
es server | source ❯ === dev === SERVICE1=dev SERVICE2=also-dev
=== prd === SERVICE1=prd SERVICE2=also-prd
echo $SERVICE1 $SERVICE2 dev also-dev ```
If you know the name of the profile you want to select, you can also skip the prompt by providing it directly to the command:
```sh
es server dev | source echo $SERVICE1 $SERVICE2 dev also-dev ```
Configuration is defined in TOML. There are two main tables in the config, each defined by a fixed key:
vars key
VARIABLE_NAME to a list of possible valuesapps key
VARIABLE = "value"Let's see this in action:
```toml
[vars] TESTVARIABLE = ["abc", "def"] OTHERVARIABLE = ["potato", "tomato"]
[apps.server] dev = {SERVICE1 = "dev", SERVICE2 = "also-dev"} prd = {SERVICE1 = "prd", SERVICE2 = "also-prd"}
[apps.empty]
[apps.big.prof1] VAR1 = "yes" VAR2 = "yes" VAR3 = "no" VAR4 = "no" VAR5 = "yes"
[apps.big.prof2] VAR1 = "no" VAR2 = "no" VAR3 = "no" VAR4 = "yes" VAR5 = "no" ```
Profiles within an app can define differing sets of variables, like so:
toml
[apps.db]
dev = {DATABASE = "dev", DB_USER = "root"}
stg = {DATABASE = "stg", DB_USER = "root", DB_PASSWORD = "goodpw"}
prd = {DATABASE = "prd", DB_USER = "root", DB_PASSWORD = "greatpw"}
The dev profile excludes the DB_PASSWORD variable. Beware though, whenever switch to the dev profile, it will simply not output a value for DB_PASSWORD. That means if you're switch from another profile, DB_PASSWORD will retain its old value! For this reason, it's generally best to define the same set of values for every profile in an app, and just use empty values as appropriate.
On every execution, env-select will scan the current directory for a file called .env-select.toml and parse it for a config. In addition to that, it will walk up the directory tree and check each ancestor directory tree for the same file. If multiple files are found, the results will be merged together, with lower config files having higher precedence. For example, if we execute es TEST_VARIABLE in ~/code/:
```toml
[vars] TEST_VARIABLE = ["abc", "def"]
[apps.server] dev = {SERVICE1 = "secret-dev-server", SERVICE2 = "another-secret-dev-server"} ```
```toml
[vars] TESTVARIABLE = ["ghi"] OTHERVARIABLE = ["potato", "tomato"]
[apps.server] dev = {SERVICE1 = "dev", SERVICE2 = "also-dev"} prd = {SERVICE1 = "prd", SERVICE2 = "also-prd"} ```
then our resulting config, at execution time, will look like:
```toml
[vars]
TESTVARIABLE = ["abc", "def", "ghi"] OTHERVARIABLE = ["potato", "tomato"]
[apps.server]
dev = {SERVICE1 = "secret-dev-server", SERVICE2 = "another-secret-dev-server"}
prd = {SERVICE1 = "prd", SERVICE2 = "also-prd"} ```
To see where env-select is loading configs from, and how they are being merged together, run the command with the --verbose (or -v) flag.
env-select supports the following shells:
If you use a different shell and would like support for it, please open an issue and I'll see what I can do!
source Disclaimerenv-select runs as a subprocess to your shell (as all commands do), meaning it cannot modify your shell environment. To get around this, env-select will simply output shell commands that you can then pipe to source to modify your session.
If you think piping stuff to source is dangerous and sPoOky, you're right. But consider the fact that at this point, you've already downloaded and executed a mystery binary on your machine. You should've already done your due diligence.
Alternatively, you can run the command without piping to source, and it will simply print out the commands to modify your environment, which you can copy-paste to run manually.
If you find a bug or have a feature request, please open an issue on GitHub.