Requirements Confusion

[MalikRumi]

Here is the result of my pip freeze after using the icecream_project template:

(klovenv)vagrant@precise64:/vagrant/ksink/icecream_project$ pip freeze
Django==1.6.2
Jinja2==2.7.2
MarkupSafe==0.23
Pygments==1.6
South==0.8.2
Sphinx==1.2.1
argparse==1.2.1
bpython==0.12
coverage==3.6
django-braces==1.2.2
django-debug-toolbar==1.0.1
django-discover-runner==0.4
django-model-utils==1.5.0
docutils==0.11
logutils==0.3.3
six==1.6.1
sqlparse==0.1.11
wsgiref==0.1.2

However, this raises a number of questions:

Why do I have discover runner when according to your own github updates it is no longer required? 924c7ae

Why do I have jinja at all? It isn’t in any requirements file. Where did it come from?

My requirements files are largely empty. I don’t understand that. I thought this template would come with “everything I needed”, at least according to the author’s view of best practices. But instead what I got, according to pip freeze, is not at all the same as what is in my requirements files. I don’t get that.

There is apparently some question about the appropriateness of gunicorn (which is in my production.txt) in this context. See http://blog.etianen.com/blog/2014/01/19/gunicorn-heroku-django/ . I’d appreciate your thoughts about this.

I'm not entirely sure this is the right place to put this. It isn't exactly a support forum - or is it? Anyway, this is where I saw I could raise these issues with the people most directly involved. Thanks and I look forward to hearing from you.

[pydanny]

Okay, lets go through the list.

1. Jinja2 is installed because Sphinx is in the requirements. Sphinx uses Jinja2 for templating of the documentation. Python packages can define their depends, and installing those packages will install those dependencies as well.
2. Just as jinja2 isn't defined in our requirements file, but Sphinx installs it, we can assume another package in this project includes it.
3. Until Heroku themselves tells us to stop using gunicorn (see https://devcenter.heroku.com/articles/python-gunicorn), we'll stay the gunicorn path. In essence, I would rather follow the formal documentation. However, I'll take this opportunity to ask @kennethreitz or @craigkerstiens to way in.