3 ms·

I've only ever used .env as such: export TWILIO_SID="123123123123" export TWILIO_SECRET="123123123123" And then `source .env` in my terminal, then `ra

I've only ever used .env as such: export TWILIO_SID="123123123123" export TWILIO_SECRET="123123123123" And then `source .env` in my terminal, then `rails server` or whatever to run my apps. The environment variables will be present to be consumed from within the app. Curious what features you use beyond this.

koolba 3y ago
> Curious what features you use beyond this. There’s plenty of outstanding questions. Is the export required? Can variables reference other variables? Can variables reference existing variables in the environment? Can you use other forms of expressions? Can you set overridable defaults for values?
- sonthonax 3y ago
  It's a shell script that should be executable by any UNIX shell. Parsing it (rather than executing it) is why those questions are raised.
  - claytongulick 3y ago
    In the nodejs community it's normally used via dotenv. So, yes it's parsed and a valid use case.
- sergiotapia 3y ago
  I've never used/needed those features from my .env files that's why I'm asking for use cases. Are you saying you use those kinds of features in python_dotenv? I'm asking btw, no snark.
  - SOLAR_FIELDS 3y ago
    I use them in python_dotenv for declaring environments that I use to provision infrastructure, as an example: Example, where we have: env_type="dev" env_name="myappenv" primary_subnet_pod="${env_type}-${env_name}-gke-pod-subnet" primary_subnet_service="${env_type}-${env_name}-gke-service-subnet" Which I then might want to use further down, override with defaults, etc and so forth. It strikes a decent balance in that it's a bit more powerful than a static .env file, but doesn't require you to go full-on templating language with Jinja and the like. It's also cross-platform enough in that you could throw a .env in somewhere and expect most languages to have a client library to parse and load it into env. If your use-case is right in that sweet spot it's a pretty good tool. But the behavior, as noted, isn't specced so I can't trust go_dotenv or rust_dotenv or whatever other library to treat it the same way. Interestingly, in practice, it seems like the Node lib is the canonical version that inspired these other ones so in a way it serves as some sort of unofficial spec. It's not something I would write production grade code trusting the unofficial spec on though.
mixedCase 3y ago
.envs generally aren't full blown shell, so you don't have `export` available. With that said, I keep a shell function in my .zshrc which, when given a .env file (or when not given one, assuming $PWD/.env) will set -a, source it and set +a, which loads everything into the environment.
bdcravens 3y ago
I always prefer to use the dotenv gem, as many times I'd rather stay local to my Rails app, rather than setting global environment variables.
zeroimpl 3y ago
If your env file is a script that you source manually, I’d call it env.sh instead. Historically this has been my approach, but in production environments it’s convenient to have a static list of variables with no “export” instead since eg systemd’s EnvironmentFile only supports that.

koolba 3y ago

> Curious what features you use beyond this. There’s plenty of outstanding questions. Is the export required? Can variables reference other variables? Can variables reference existing variables in the environment? Can you use other forms of expressions? Can you set overridable defaults for values?

sonthonax 3y ago
It's a shell script that should be executable by any UNIX shell. Parsing it (rather than executing it) is why those questions are raised.
- claytongulick 3y ago
  In the nodejs community it's normally used via dotenv. So, yes it's parsed and a valid use case.
sergiotapia 3y ago
I've never used/needed those features from my .env files that's why I'm asking for use cases. Are you saying you use those kinds of features in python_dotenv? I'm asking btw, no snark.
- SOLAR_FIELDS 3y ago
  I use them in python_dotenv for declaring environments that I use to provision infrastructure, as an example: Example, where we have: env_type="dev" env_name="myappenv" primary_subnet_pod="${env_type}-${env_name}-gke-pod-subnet" primary_subnet_service="${env_type}-${env_name}-gke-service-subnet" Which I then might want to use further down, override with defaults, etc and so forth. It strikes a decent balance in that it's a bit more powerful than a static .env file, but doesn't require you to go full-on templating language with Jinja and the like. It's also cross-platform enough in that you could throw a .env in somewhere and expect most languages to have a client library to parse and load it into env. If your use-case is right in that sweet spot it's a pretty good tool. But the behavior, as noted, isn't specced so I can't trust go_dotenv or rust_dotenv or whatever other library to treat it the same way. Interestingly, in practice, it seems like the Node lib is the canonical version that inspired these other ones so in a way it serves as some sort of unofficial spec. It's not something I would write production grade code trusting the unofficial spec on though.

mixedCase 3y ago

.envs generally aren't full blown shell, so you don't have `export` available. With that said, I keep a shell function in my .zshrc which, when given a .env file (or when not given one, assuming $PWD/.env) will set -a, source it and set +a, which loads everything into the environment.

bdcravens 3y ago

I always prefer to use the dotenv gem, as many times I'd rather stay local to my Rails app, rather than setting global environment variables.

zeroimpl 3y ago

If your env file is a script that you source manually, I’d call it env.sh instead. Historically this has been my approach, but in production environments it’s convenient to have a static list of variables with no “export” instead since eg systemd’s EnvironmentFile only supports that.