envbash 2.0.0

How is this different from dotenv?

Both projects aim to solve the same problem, but differ in approach. In particular, dotenv uses an ad hoc config syntax whereas envbash uses Bash.

dotenv’s syntax becomes a problem with multi-line strings. dotenv intends for the .env file to be readable by the shell, but the dotenv format for multi-line strings isn’t compatible with the shell.

If the point is to have a configuration language that’s well-suited to environment variables, it’s hard to beat pure Bash, and it’s guaranteed to source properly into the shell.

Should I commit env.bash to source control?

No, definitely not. The purpose of env.bash is to store development configuration that isn’t suitable for committing to the repository, whether that’s secret keys or developer-specific customizations. In fact, you should add the following line to .gitignore:

/env.bash

Is it necessary to explicitly export variables in env.bash?

No, envbash prefixes sourcing your env.bash with set -a which causes all newly-set variables to be exported automatically. If you would rather explicitly export variables, you can set +a at the top of your env.bash.

How do I put a multi-line string into env.bash?

You can put newlines directly into a multi-line string in Bash, so for example this works:

PRIVATE_KEY="
-----BEGIN RSA PRIVATE KEY-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END RSA PRIVATE KEY-----"

Does envbash override my environment settings?

By default your local environment settings win, so you can override the content of env.bash by explicitly exporting variables in your shell.

You can change this behavior. This makes sense for a deployed instance that gets full configuration from env.bash and needs to be protected from the calling environment.

load_envbash('env.bash', override=True)

Can I remove settings from the environment?

By default envbash doesn’t remove settings, but you can change this behavior.

load_envbash('env.bash', remove=True)

This will cause any variables that you explicitly unset in env.bash to be removed from Python’s os.environ as well.

How do I source env.bash into my guest shell environment?

Assuming that your source directory is available on the default /vagrant mount point in the guest, you can add add this line at the bottom of /home/vagrant/.bash_profile:

set -a; source /vagrant/env.bash; set +a

Note that this means that settings are loaded on vagrant ssh so you need to exit the shell and rerun vagrant ssh to refresh if you change settings.

What about Ruby?

See envbash-ruby