4 ms·

export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv pr

export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.

netcraft 3y ago
I tend to agree, and we do this a lot actually. But it gets a little more complicated if you have several .env files. Would love to hear more about why dotenv is banned at your org though.
- whalesalad 3y ago
  Because I banned it haha. There should not be more than one .env file. Our projects have a .env.example that has any overrides a dev might want to override but this list is kept intentionally very short. Meanwhile .env is noted in gitignore. I absolutely hate seeing an entire application configured with environment variables. Some? Sure, where it makes sense. Most? No, those should be in version control, secrets aside. I believe in convention over configuration. Most of our apps have hard-coded config, with a concise/short and finite number of things that can be overridden (like 3-4 parameters, tops). Secrets get injected. I do subscribe to the idea of the 12 factor app, but there is a line that needs to be drawn between env config which is more dynamic and more persistent config that should be baked in to the release.
  - sureglymop 3y ago
    To add to that, SOME_SECRET env vars should be banned (or at least overridable) in favor of SOME_SECRET_FILE env vars. I usually just put an example of the env vars into the readme or link to the file in the source code handling that directly.
  - silversmith 3y ago
    But then the problem is changing configs means building a new release, and needs code push access. Pretty much every config variable has env override in my apps - allows project owner to poke about in web UI without bothering me for changes.
macintux 3y ago
Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.
- whalesalad 3y ago
  That is kinda the purpose of an environment.
  - macintux 3y ago
    I jump around between multiple projects every day. Sticky environment variables carry risk.
    - whalesalad 3y ago
      I would suggest using a tool like tmux to partition those projects entirely. Instead of tearing down env and building it back up to switch projects, just re-attach to that tmux session. I treat this stuff as though it’s immutable and try to consciously avoid cross pollination.
      - macintux 3y ago
        That’s reasonable, but my point stands: your original proposal is insufficient to be treated as equivalent.
        colimbarna 3y ago
        env $(cat .env) my-cmd-wanting-dotenv would, though, wouldn't it? ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a configurable sub-environment for a command" and we can avoid subtle distinctions.
bentinata 3y ago
What about: env $(cat .env) [program]
- arjvik 3y ago
  Has whitespace handling issues... but valiant effort!
fire_lake 3y ago
When your environment variable values have spaces (e.g. some connection strings) this doesn’t work iirc

export $(cat .env | xargs) Agree with the premise but this can be achieved with actual Unix concepts no need for anything else. The language runtime dotenv projects are banned in my engineering org.

netcraft 3y ago

I tend to agree, and we do this a lot actually. But it gets a little more complicated if you have several .env files. Would love to hear more about why dotenv is banned at your org though.

whalesalad 3y ago
Because I banned it haha. There should not be more than one .env file. Our projects have a .env.example that has any overrides a dev might want to override but this list is kept intentionally very short. Meanwhile .env is noted in gitignore. I absolutely hate seeing an entire application configured with environment variables. Some? Sure, where it makes sense. Most? No, those should be in version control, secrets aside. I believe in convention over configuration. Most of our apps have hard-coded config, with a concise/short and finite number of things that can be overridden (like 3-4 parameters, tops). Secrets get injected. I do subscribe to the idea of the 12 factor app, but there is a line that needs to be drawn between env config which is more dynamic and more persistent config that should be baked in to the release.
- sureglymop 3y ago
  To add to that, SOME_SECRET env vars should be banned (or at least overridable) in favor of SOME_SECRET_FILE env vars. I usually just put an example of the env vars into the readme or link to the file in the source code handling that directly.
- silversmith 3y ago
  But then the problem is changing configs means building a new release, and needs code push access. Pretty much every config variable has env override in my apps - allows project owner to poke about in web UI without bothering me for changes.

macintux 3y ago

Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.

whalesalad 3y ago
That is kinda the purpose of an environment.
- macintux 3y ago
  I jump around between multiple projects every day. Sticky environment variables carry risk.
  - whalesalad 3y ago
    I would suggest using a tool like tmux to partition those projects entirely. Instead of tearing down env and building it back up to switch projects, just re-attach to that tmux session. I treat this stuff as though it’s immutable and try to consciously avoid cross pollination.
    - macintux 3y ago
      That’s reasonable, but my point stands: your original proposal is insufficient to be treated as equivalent.
      - colimbarna 3y ago
        env $(cat .env) my-cmd-wanting-dotenv would, though, wouldn't it? ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a configurable sub-environment for a command" and we can avoid subtle distinctions.

bentinata 3y ago

What about: env $(cat .env) [program]

arjvik 3y ago
Has whitespace handling issues... but valiant effort!

fire_lake 3y ago

When your environment variable values have spaces (e.g. some connection strings) this doesn’t work iirc