Cookiecutter-django: How do I use the env.sample?

Created on 24 Feb 2016  路  25Comments  路  Source: pydanny/cookiecutter-django

There's a env.sample file but I can't find a note on how I can use it in the documentation.

docs help wanted

Most helpful comment

I'm also a cookiecutter newbie and agree how to use the .env file is not obvious.

Where is the best practices place to put the .env file? Where sample.env is? in config/settings/?, or outside of the repository?

Also where is the best place to read the .env file. In common.py?, local.py?, or someplace else?

thanks

All 25 comments

I guess you are talking about env.example.

  1. You make a copy of it and call it .env (hidden in many OS GUIs)
  2. Then you enter the data for your environment.
    Example: DJANGO_SECRET_KEY=asdasd;kfj3@#$asdkfjasdjkfk3G4ASDFASF
    .oO( cat on keyboard _giggle_ )
  3. In your settings file (e.g. common.py) you can read it like so: env.read_env(ROOT_DIR('.env')) depending on where you put your copy.

Does that help @pcompassion?

env.example is documented in https://github.com/pydanny/cookiecutter-django/blob/8a7ecb0ca74a4e3376eb3bc79dcaedd6f3e94244/docs/deployment-with-docker.rst.

Thanks for answering @Eraldo! You think maybe we should expand that documentation?

yes it helps.. (env.example is needed for installation without docker so I think it's proper to include in the other install doc)

Thanks for that answer @Eraldo , just helped me out of a long-standing jam. Having come recently to the cookie-cutter world, the usage of the env.example/.env file isn't obvious, particularly for those of us that haven't worked up to Docker yet - expanding the explanation would be really helpful.

If anyone wants to add this to the documentation, we'd love a pull request 馃槃

I'm also a cookiecutter newbie and agree how to use the .env file is not obvious.

Where is the best practices place to put the .env file? Where sample.env is? in config/settings/?, or outside of the repository?

Also where is the best place to read the .env file. In common.py?, local.py?, or someplace else?

thanks

Yeah, this definitely needs better documentation especially for someone who is new to Django. It took some trial and error to figure out that I have to add env.read_env(ROOT_DIR('.env')) to common.py. For the uninitiated, add it after this line env = environ.Env().

@Intelbob, while you're code works, the .env file is meant to be read by configuration tools as environment variables, not read directly in the python code. It's meant to provide a seperation of concerns for Docker-powered tools, not as a general coding method.

Sigh. This needs to be documented better. The problem is lack of free time. :(

@shevitz, .env is meant for user with Docker. If you aren't using Docker, you should be seeing environment variables locally or via configuration management tools.

Ping @jayfk, any thoughts? Am I correct about seperation of concerns,?

@pydanny good to know but how would I do that again? Keep in mind I'm a Django newbie :) Environ documentation does not seem to indicate that either, https://django-environ.readthedocs.io/en/latest/

I am also a bit confused about the relationship between .env with this setting DJANGO_SETTINGS_MODULE=config.settings.local and the settings insettings/local.py.

I should also add that I am using a remote Postgres DB for both development and production, so I am trying to figure out where to best store the settings for all the environments.

django vs sys-admin
@IntelBob As I see it, what @pydanny is referring to is that the where/how you set the specific django settings is not related to your "django" knowledge level.. but rather a sys-admin matter.

in other words
If I am a newbie when it comes to environment variables and how to set them, I might have difficulties configuring django in the desired way -- however that does have little to do with django. ;)

advantage
In my opinion that is a good thing. It means that different people can use different methods of setting these variables depending on their environment (thus the name environment variable).

file is an option
And yes, reading in the values from another file (like .env) directly from within the settings file is an option -- however that is not the "recommended" or "preferred" method afaik.

rationale
There might be some systems (like PAAS) where you do not have enough access to set the environment variables. In that case it's very cool to still be able/flexible to use a plain file.

adjusting to your system
That being said. I personally use both direct and file based configuration with some of my projects.

documentation in future
I am willing to do some basic documentation. However I will not get to it in the next couple of days. So if you guys can still wait a little I will be glad to help out trying to add some words and links of clarity.

further discussion
In the meantime feel free to ask specific questions here or even add stuff you want included and I will try to incorporate them. :)

thanks @pydanny for the clarification. I ended up implementing what @IntelBob suggested independently. Now I find out differently. I'm ok with environment variables, it's just there are lots of places to set them on my dev box. I can set them in .bashrc, .activate, .postactivate. My guess is that best practices is in .postactivate. I'm already setting stuff there.

@Eraldo thanks for the lengthy explanation, yes I got the sysadmin part after playing around with it some more. Since I am new to Django and its vast ecosystem, it's hard initially to tell what's what until I learn more about each component. What's also partly confusing is the environ documentation that has code sample with environ.Env.read_env() # reading .env file and no mention of docker which is the apparent use of .env for cookiecutter. For now, I'll look into configuration tool to set env variables, @pydanny suggestion of using .postactivate sounds like an option.

I'm guessing that for an Ubuntu system the ~/.pam_environment would be a good candidate for setting the variables in alternative to .env?

The current default seems to expect .env to be located in config/settings/, FYI.

@tobiasmcnulty That's news to me. That said, I've been working with Elastic Beanstalk for a while now and haven't touch Docker for a few months. @jayfk, are you noticing that too?

@tobiasmcnulty, delighted to see a member of Caktus here. 馃槃

Wow, this whole time I'd assumed that .env file was getting read/used by my app. Took me several hours to figure out what the problem was. o__O (I use .env files for other projects of mine, so I _naturally_ assumed that that was where the variables would go...)

What... exactly is the plan for documenting this? This is extremely confusing, especially for folks who might not be super familiar with the database they are using for their new/first/... Django project. ("Did I set up the DB incorrectly? Did I mess up the DB settings in Django? Are there other settings overriding the settings I want to use?")

Where are non-Docker users supposed to put their vars if they wanted to do it similar to how it's done in other Django example apps (which use one single settings.py file that's not version-controlled)? I'm really unsure about how to translate the info found there to an app built with cookiecutter.

Waaaaait, I only realised _now_ (10 days later!) that I could have used the .env file alright, I was just missing instructions on _how_ to use it. /;

951 fixes this in the .env sample file, though I guess it would be best to also add this to the documentation.

There is a mismatch between what the docker files and django expects. Docker expects .env to be in the root directory. Django settings are trying to locate it in /config/settings.

Replacing in /config/settings/common.py

env = environ.Env()
# env.read_env()

with

env = environ.Env()
env.read_env(ROOT_DIR('.env'))

as stated before will do the trick. Then obviously also rename env.example to .env

@philippeluickx Hmm, not sure who your comment was directed at.

I didn't have too much of a problem figuring out where to put the .env file (settings/config seemed like a logical choice what with all other settings going there), it was more about: why is there an .env file but no info about it, and with people saying it's only meant for Docker: why is there a file only meant for Docker when I picked "No" for Docker during installation, and why can't I use it too or where else am I supposed to put my vars?

why is there a file only meant for Docker when I picked "No" for Docker during installation, and why can't I use it too or where else am I supposed to put my vars?

Because people are not perfect and introduce bugs.

@kerstin There were mentions that the .env file was not used (including yourself). My comment was to point out how to make it work.

I don't want to take the credit. I just noticed that the way it is currently implemented (just started a new project with Docker) has an issue:

Edit: improvements on their way: https://github.com/pydanny/cookiecutter-django/pull/985
Edit2: There also seems to be a consensus that .env should only be used with Docker. With the mentioned pull request, using .env will become optional. However, I find it useful without Docker too.

@jayfk Certainly, it's just not necessarily clear to people new to a project. (:

This has been reworked and improved in #1295 (thanks @webyneter). The env files are now pre-generated as described in the documentation, and the sample/example file doesn't exist anymore.

Was this page helpful?
0 / 5 - 0 ratings