Answers: <p>check out <a href="https://direnv.net/" rel="nofollow noreferrer">https://direnv.net/</a> it sets environment variables based on the directory you are in.</p>
  
  <p>other options are:
  1.docker-compose
  2.plain bash to set the variables.
  3. bash source .env
  4. use prefixes but you would still need to set the environment you are in via an environment variable, so back to options 1-3.</p>
  
  <p>if you are going to store passwords or keys in the env variables locally that are sensitive i.e not a localhost db pass, use a secrets manager like <a href="https://pkhub.io/usecases/environments" rel="nofollow noreferrer">https://pkhub.io/usecases/environments</a>, or you could script up something with aws' secrets manager</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-08-14T11:04:18.703Z
Answers: 2019-08-14T11:04:18.703Z
Answers: gerritjvv
Answers: <p>Not sure if this is the first, but it surely won't be the last time. Having a script that starts a new shell (new container, new VM) with environment setup for the development of the project you will be working on next is something you will definitely need in the future. If there are multiple people collaborating, it is even more important. If you get into the habit of using it now, future changes will be easier.</p>
  
  <p>The reason why you set it in new shell (container/VM) is that you can easily exit to unset the environment and enter a new one for a different project and because you might need to set a different user or group memberships for the project.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-15T23:33:14.410Z
Answers: I don't typically run my development environment in a container - it just runs on my machine. Wouldn't file watching be problematic running on a container?
Answers: dwjohnston
Answers: CC BY-SA 4.0
Answers: 2018-10-16T00:24:32.477Z
Answers: That was an alternative. In the most basic way you use a script with one argument being the project name and it knows where to get the settings, then it starts a new sub-shell where it sets the correct groups (if needed) and environment for that project. Once you are done working on it, you simply type 'exit' and you are back to your vanilla environment and can execute it with another project name.
Answers: Jiri Klouda
Answers: CC BY-SA 4.0
Answers: 2018-10-16T00:28:01.730Z
Answers: If you use one repo per project, then you should always have a script of the same name in the root of the repo, like setup_env.sh then put all your repos in standard location and write a wrapper script that will cd to $HOME/co/$PROJECT_NAME and source (or exec) $HOME/co/$PROJECT_NAME/setup_env.sh
Answers: Jiri Klouda
Answers: CC BY-SA 4.0
Answers: 2018-10-15T16:51:12.977Z
Answers: 2018-10-15T16:51:12.977Z
Answers: Jiri Klouda
Body: <p>The context is that I'm looking at doing staging/testing and production on a  kubernetes cluster. </p>
  
  <p>Where I might have some code that looks like this:</p>
  
  <pre><code>doSomething({
    username: process.env.DB_USERNAME,
    password: process.env.DB_PASSWORD
  })
  </code></pre>
  
  <p>For my various kubernetes environments, this isn't going to be a problem, as those environment variables can be set specifically for the environment. </p>
  
  <p>However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named <code>DB_URL</code>. </p>
  
  <p>One solution would be to just prefix all environment variables with <code>MY_APPLICATION_NAME_</code>. </p>
  
  <p>Another would be not permanently set environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy. </p>
  
  <p>I'm wondering if there's a well established way that deals with this problem. </p>
  
Tags: <environment-variables>
Title: Environment variable names, when my development environment has multiple projects
UserDisplayName: dwjohnston
ThreadText: # Environment variable names, when my development environment has multiple projects
  
  (Asked by: username_0 on 2018-10-15)
  
  The context is that I'm looking at doing staging/testing and production on a kubernetes cluster.
  
  Where I might have some code that looks like this:
  
  ```
  doSomething({
    username: process.env.DB_USERNAME,
    password: process.env.DB_PASSWORD
  })
  
  ```
  
  For my various kubernetes environments, this isn't going to be a problem, as those environment variables can be set specifically for the environment.
  
  However, for my development environment, there's a good chance that I'm going to have multiple projects, (or even different images for the same project) that all have a environment variable named `DB_URL`.
  
  One solution would be to just prefix all environment variables with `MY_APPLICATION_NAME_`.
  
  Another would be not permanently set environment variables, but instead to just call a script that sets them when needed. But that sounds a little messy.
  
  I'm wondering if there's a well established way that deals with this problem.
  
  **Tags:** environment-variables
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-08-14. Score: 1
  
  check out <https://direnv.net/> it sets environment variables based on the directory you are in.
  
  other options are:
  1.docker-compose
  2.plain bash to set the variables.
  3. bash source .env
  4. use prefixes but you would still need to set the environment you are in via an environment variable, so back to options 1-3.
  
  if you are going to store passwords or keys in the env variables locally that are sensitive i.e not a localhost db pass, use a secrets manager like <https://pkhub.io/usecases/environments>, or you could script up something with aws' secrets manager
  
  
  ---
  
  ### Answer by username_2 on 2018-10-15. Score: 0
  
  Not sure if this is the first, but it surely won't be the last time. Having a script that starts a new shell (new container, new VM) with environment setup for the development of the project you will be working on next is something you will definitely need in the future. If there are multiple people collaborating, it is even more important. If you get into the habit of using it now, future changes will be easier.
  
  The reason why you set it in new shell (container/VM) is that you can easily exit to unset the environment and enter a new one for a different project and because you might need to set a different user or group memberships for the project.
  
  > **Comments:**
  > **username_0**: I don't typically run my development environment in a container - it just runs on my machine. Wouldn't file watching be problematic running on a container?  
  > **username_2**: That was an alternative. In the most basic way you use a script with one argument being the project name and it knows where to get the settings, then it starts a new sub-shell where it sets the correct groups (if needed) and environment for that project. Once you are done working on it, you simply type 'exit' and you are back to your vanilla environment and can execute it with another project name.  
  > **username_2**: If you use one repo per project, then you should always have a script of the same name in the root of the repo, like setup_env.sh then put all your repos in standard location and write a wrapper script that will cd to $HOME/co/$PROJECT_NAME and source (or exec) $HOME/co/$PROJECT_NAME/setup_env.sh  
  
  ---
  
  