3 ms·

What happens when, 30 commands later, you execute a command in your shell and didn't remember that message from a day or so ago?

malicka 3y ago
It’s the same as forgetting you put something in your .profile or .bashrc, no? In any case, both forgetting the env config and using the same shell for days in a row seem like two things that probably don’t coincide too often.
- jeffhuys 3y ago
  I never close my shell, I never reboot my laptop unless necessary - an uptime of 6+ months is normal. So my experience may be different.
  - withinboredom 3y ago
    How do you deal with kernel security patches?
kreetx 3y ago
Of you're in the directory, don't you want the env to be loaded? For me, being able to forget it is one of the features.
- steezeburger 3y ago
  Not always. I can think of a scenario where I have an env I need to load for some infrastructure stuff, and I may call some commands in a directory that has another .env that's part of what I'm trying to deploy. Generally this scenario is short lived as I'm quickly moving infra commands to automated ci/cd, but I've definitely been in this scenario more than once.
  - kreetx 3y ago
    Got it! I think nested envs become confusing really quickly, so there it is indeed better to do it explicitly. My assumption overall in this is that most people have just one .env per project (or perhaps in sub-folders per environment, e.g prod, staging, local), but these don't nest. With nested .env files, the mental overhead they bring remove (IMO) most of the benefits, if not more.
heurist 3y ago
If you use direnv you always know your environment is loaded (assuming you've formed the script properly and allowed direnv to run it). And that's what you want. It's a way to keep your workspaces distinct in the terminal environment. You set what you need to set to be able to do what you need to do from any particular directory.

malicka 3y ago

It’s the same as forgetting you put something in your .profile or .bashrc, no? In any case, both forgetting the env config and using the same shell for days in a row seem like two things that probably don’t coincide too often.

jeffhuys 3y ago
I never close my shell, I never reboot my laptop unless necessary - an uptime of 6+ months is normal. So my experience may be different.
- withinboredom 3y ago
  How do you deal with kernel security patches?

kreetx 3y ago

Of you're in the directory, don't you want the env to be loaded? For me, being able to forget it is one of the features.

steezeburger 3y ago
Not always. I can think of a scenario where I have an env I need to load for some infrastructure stuff, and I may call some commands in a directory that has another .env that's part of what I'm trying to deploy. Generally this scenario is short lived as I'm quickly moving infra commands to automated ci/cd, but I've definitely been in this scenario more than once.
- kreetx 3y ago
  Got it! I think nested envs become confusing really quickly, so there it is indeed better to do it explicitly. My assumption overall in this is that most people have just one .env per project (or perhaps in sub-folders per environment, e.g prod, staging, local), but these don't nest. With nested .env files, the mental overhead they bring remove (IMO) most of the benefits, if not more.

heurist 3y ago

If you use direnv you always know your environment is loaded (assuming you've formed the script properly and allowed direnv to run it). And that's what you want. It's a way to keep your workspaces distinct in the terminal environment. You set what you need to set to be able to do what you need to do from any particular directory.