Looking for .env in the wrong place

[metakermit]

I tried your package with a test.py script and a .env file in the same directory. Running ./test.py does not source the .env file. It seems that it is looking for it in the site-packages folder of the virtualenv - once I move the .env file there, it works. Is this expected behaviour? I normally (e.g. with Honcho/Foreman) keep the .env file in the root of the project, not in the site-packages/ folder.

[driesdesmet]

This is expected behaviour, although your mileage may vary. I usually link the .env file back to the root of my project while developing, so I can reach it easily. But I coded it this way because if I choose to install my project onto a production server as opposed to just checking out the source code, there is no way to tell where I installed the source code, but there is always a a way to know where the virtualenv directory is or indeed the python executable that was used to run the project.

I've since found that this whole approach is actually not recommended, because it overwrites sitecustomize.py (or the python package sitecustomize). It sort of works when using virtualenvs in which case you have a python executable for every virtualenv, but it is not good practice in general. I'm still on the lookout for a better solution to run several django project on a shared host. I now use honcho or foreman to export to supervisord but I've always found that it's quite cumbersome. I always need to edit the supervisord snippets it creates.

[metakermit]

Ah, yes. I understand what you mean. OK, we can close this if you like, then (optionally maybe expand the README a bit).

Yes, I've also been reading on it - could usercustomize maybe work better? That one is not supposed to be used by any other packages. But yes, I agree that the solution is still not that smooth. I also have problems getting supervisord to use the virtualenv and source the environment variables - especially from ansible, where I still can't figure out how to activate a virtualenv for good. It's just one of those things that sounds so simple in theory - get whatever server to use a certain python binary and a certain set of env. variables; but is very difficult to achieve in all tools, due to lack of concensus.