3 ms·

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.
    - malicka 3y ago
      Several people, including you, are proposing using env rather than sourcing; is that somehow preferable to something like this? (. .env; my-cmd)
      - colimbarna 3y ago
        See my comment sibling to yours for some concerns with `env $(cat file)`; I would have these and then some with sourcing the file even in a subshell. You can do whatever you want in a shell script which can have effects outside of the subshell. Another advantage of env is that you can type `man env` and learn something useful; sourcing and subshells via syntax is a little bit harder. Finally, I think the major point of this branch of the discussion is to explicitly decorate a command with a special environment. Starting up a subshell isn't the same thing. It might have the same effect, but you can see that you're creating a subshell, running a builtin in the subshell, and then running a command in the subshell. It is something of a difference between declarative (dotenv/env) and imperative (sourcing in a subshell) approaches, and inherits all the pros and cons of the imperative approach. If it works for you, I make no recommendation against it.
    - colimbarna 3y ago
      Further addition, I haven't investigated dotenv deeply, but I suppose it would be a command that specialises in making sure the contents of .env are just environmental variables that get defined. The `env` command as I wrote it is probably not the sort of thing you want to just trust on a file in a git repo shared with colleagues. Anyway, like my ETA above suggests I'm in two minds about whether env and dotenv should be the same thing with different arguments or not.

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.
  - malicka 3y ago
    Several people, including you, are proposing using env rather than sourcing; is that somehow preferable to something like this? (. .env; my-cmd)
    - colimbarna 3y ago
      See my comment sibling to yours for some concerns with `env $(cat file)`; I would have these and then some with sourcing the file even in a subshell. You can do whatever you want in a shell script which can have effects outside of the subshell. Another advantage of env is that you can type `man env` and learn something useful; sourcing and subshells via syntax is a little bit harder. Finally, I think the major point of this branch of the discussion is to explicitly decorate a command with a special environment. Starting up a subshell isn't the same thing. It might have the same effect, but you can see that you're creating a subshell, running a builtin in the subshell, and then running a command in the subshell. It is something of a difference between declarative (dotenv/env) and imperative (sourcing in a subshell) approaches, and inherits all the pros and cons of the imperative approach. If it works for you, I make no recommendation against it.
  - colimbarna 3y ago
    Further addition, I haven't investigated dotenv deeply, but I suppose it would be a command that specialises in making sure the contents of .env are just environmental variables that get defined. The `env` command as I wrote it is probably not the sort of thing you want to just trust on a file in a git repo shared with colleagues. Anyway, like my ETA above suggests I'm in two minds about whether env and dotenv should be the same thing with different arguments or not.