Profile specific environment variable

[mayanand]

This library is awesome and I am planning to use it in my application. I am wondering if I could suggest an enhancement which allows depoyment specific configuration variables using this library.

I am proposing to allow multiple .env files such as

• .env : default file that contains configuration that is common across different deployment environments
• .env.stage: contains configuration specific to stage deployment. For ex. URL for stage DB
• .env.production: contains configuration specific to production deployment. For ex, URL for production DB

This is similar to profile specific configuration that Spring allows. Link here

What do you guys think about it. I am happy to raise a PR for it.

[mayanand]

@theskumar Please let me know your views on it.

[theskumar]

Depending on your application deployment logic, you can point to different .env file during it's initialisation i.e. call to

if ENV == 'production':
  dotenv_file = '.env.production'
elif ENV == 'stage':
  dotenv_file = '.env.stage'
else:
  dotenv_file = '.env'

load_dotenv(dotenv_file)

Adding this logic is very much application dependent and varies a lot across project types, so adding this to dotenv doesn't add much value.

[mayanand]

@theskumar yes that is right. The only challenge in this approach is the duplication of variables which are common across different deployments. Is there a way of getting common variables from a default .env file and then based on the app deployment logic I could update it using the workflow that you suggested. Something similar to:

# load default variable
dotenv_file_list = [".env"]

if ENV == 'production':
  dotenv_file_list.append('.env.production')
elif ENV == 'stage':
  dotenv_file_list.append('.env.stage')
else:
  pass

load_dotenv_files(dotenv_file_list)

We can add a new API like load_dotenv_files Where values from env specific file will be updated to default values. Do you think it makes any sense to add it dotenv?

[mayanand]

@theskumar ^^^ WDYT?

[bbc2]

I think you can avoid the duplication of variables with the following approach:

if ENV == 'production':
    load_dotenv('.env.production')
elif ENV == 'staging':
    load_dotenv('.env.staging')
load_dotenv('.env')

This works because, by default, load_dotenv doesn't override previously defined values.

You could load .env first and pass override=True for .env.production and .env.staging to change that, but it would also prevent you from overriding the value from the environment.

Does this solve your use case?

I have to say though, my impression is that .env files are only used in development, and that libraries like python-dotenv are for the developer's convenience. When an application is deployed, it should get its configuration from the actual environment. For instance, that's a requirement on Heroku, but is also possible if you manage your infrastructure (e.g. systemd can set environment variables).

[yalegria]

Hello, sorry for opening this. My use case is very similar. Instead of having stage, production and/or qa .env files which can be easily set using the above approaches, in my case the variables are project-based, that is, the variables are dependent on a project such as project id and secret. In other words, my application will be used for unlimited projects ( x number) as opposed to defined number (dev, qa, prod).

Any suggestions.

[akapoor20]

Can we have some more discussion on this.. my requirement is exactly like @yalegria, any suggestion would be great...