8

Where is the common location/directory to store configuration in a python virtualenv?

For Linux there is /etc for user stuff there is XDG_CONFIG_HOME (~/.config) but for virtualenv ...?

I know that I can store my configuration in any location that I want, but maybe there is a common location, which makes my application easier to understand by python experts.

guettli
  • 25,042
  • 81
  • 346
  • 663
  • I've tried to provide a survey of the most common options in my answer below to avoid having this question flagged for being opinion / discussion. – Taylor D. Edmiston May 04 '16 at 20:20
  • @tedmiston yes, this question is not like "how to add two integers in python?", there are is not one single correct answer. Since there are already three up-votes, I don't think the StackO police will notice this opinion/discussion question ... yes, strictly reading the StackO rules, this question should be closed :-) – guettli May 05 '16 at 07:37
  • I'm hoping someone else will add another reply for comparison. This is certainly a problem that all of us have. – Taylor D. Edmiston May 06 '16 at 17:44

1 Answers1

6

So I think this is the most common approach...

1. postactivate with virtualenvwrapper

I've always done this in the postactivate file myself. In this approach, you can either define environment variables directly in that file (my preference) or in a separate file in your project dir which you source in the postactivate file. To be specific, this is actually a part of virtualenvwrapper, as opposed to virtualenv itself.

http://virtualenvwrapper.readthedocs.io/en/latest/scripts.html#postactivate

(If you want to be really clean, you can also unset your environment vars in the postdeactivate file.)

Alternatively, you can do this directly in the activate file. I find that approach less desirable because there are other things going on in there too.

https://virtualenv.pypa.io/en/latest/userguide.html#activate-script

Two popular alternatives I've also used are:

2. .env with autoenv

Independent of virtualenv, another approach towards solving the same problem is Kenneth Reitz' autoenv, which automatically sources a .env whenever you cd into the project directory. I do not use this one much anymore.

https://github.com/kennethreitz/autoenv

3. .env with Python Decouple

If you only need the environment variables for Python code (and not, for example, in a shell script inside your project) then Python Decouple is a related approach which uses a simplified .env file in the root of your project. I find myself using it more and more these days personally.

https://github.com/henriquebastos/python-decouple/

I'm somewhat surprised to see this is not discussed in detail in The Hitchhiker's Guide to Python - Virtual Environments. Perhaps we can generate a pull request about it from this question.

Taylor D. Edmiston
  • 12,088
  • 6
  • 56
  • 76
  • Which of these approaches work for processes, which are not started from a shell? For example systemd daemon or wsgi-worker? – guettli Jul 25 '16 at 08:49
  • @guettli I'm not totally sure (not something I've tried), but I think #3 might be easier for this approach than others because it reads at runtime vs when the virtual env is activated. This assumes you only need your environment variables inside the Python process and not other processes. For the others, you might try this approach, though I haven't tested it - https://discourse.mafiasi.de/t/python-virtualenv-and-systemd-for-graphite/652. – Taylor D. Edmiston Jul 25 '16 at 13:32