An option to specify .env filename

[balta2ar]

Hi. Similarly to django-configurations, it could be very convenient to be able to specify an environment filename with variables, not just to have .env hard-coded. For example, I could therefore specify a set of vars for different environments, e.g. prod.env, staging.env, and I could switch them using another env variable, e.g.:

DECOUPLE_CONFIGURATION=staging.env python program.py

[rednaks]

Hi @balta2ar while I think it's a good idea too, and thinking about the best way how to implement it, you're still can use from decouple import AutoConfig and use the search_path argument:

config = AutoConfig(search_path='./staging-env/') 

while your you have this ./stagin-env/.env

[rednaks]

Here is a proposal to support a custom config file name https://github.com/henriquebastos/python-decouple/pull/76/files

[henriquebastos]

I don't understand the need for this since the role purpose of decouple is to avoid having different settings layouts. The values may change on each instance, but the keys must all be the same in every environment.

Can anyone detail a concrete and real use case for this?

[pirate]

Running Django tests is an example of a special case where values in .env should be ignored in favor of a different hardcoded file. e.g. we often want to swap out the entire DB configuration to use an in-memory db or a specific postgres db when testing. Granted, there are other ways to accomplish this, but being able to specify the path to an arbitrary anything.env file would make it very easy.

[hkpypy]

I don't understand the need for this since the role purpose of decouple is to avoid having different settings layouts. The values may change on each instance, but the keys must all be the same in every environment.

Can anyone detail a concrete and real use case for this?
In every instance I could have 2 env files (.env, test.env) .env file for application and test.env file for test cases. this is the basic need.

[henriquebastos]

@pirate so this seems to be specific for you where your workflow is not align with decouple's design guide. No problem.

The easy way to deal with this kind of particularity is to compliment your workflow with some shell alias or makefile to link the proper file as .env prior to run a command.

For instance:

alias runtests=ln -s test.env .env && manage.py test
alias runserver=ln -s dev.env .env && manage.py runserver