Hacker News Reader

Comment by LeafStorm | Hacker News Reader

One thing that I think the Django core team needs to work on is documenting best practices. And I know that there are a bunch of different huge companies who build things in Django and all have different standards for how to develop and deploy, but just running

    $ django-admin.py startproject PROJECT
    $ cd PROJECT
    $ python manage.py startapp

is simply not cutting it.

View on HN

I've always thought there has been dissonance between the remarkable amount of "this is how we did it at the paper" baked into the code and the libertarian "you should do what works for you" in the docs.

(What worked at the paper has always worked well for me, of course, but I've never been too adventurous about straying.)

Why? Django (trunk) has new files layout.

    $ django-admin.py startproject testo 
    $ cd testo
    $ ./manage.py startapp testapp

    $ tree                                                                                                    
    .
    ├── manage.py
    ├── testapp
    │   ├── __init__.py
    │   ├── models.py
    │   ├── tests.py
    │   └── views.py
    └── testo
        ├── __init__.py
        ├── settings.py
        ├── urls.py
        └── wsgi.py

...You know, this actually makes a heck of a lot more sense. Hopefully they'll follow it up with some more docs on how you can develop with virtualenv and the like.

I totally agree - having no standards around common problems (like how to deal with tests once they get too big for a single tests.py) is extremely inconvenient.

That's because Django, while monolithic, is in many ways based on pythonic principles.

In Ruby, for instance, you really need conventions as in Ruby the concept of packages and how they get included / used is a lot more relaxed.

In Python tests.py is a package as far as Python is concerned. If it gets too big you can make it a directory and break its contents in several sub-packages. I did this with everything else too, like views.py or models.py

The one concept Django has that I consider a flaw is in fact non-pythonic - apps. That's because apps are not just simple packages. Instead apps are packages that have to be specified in an INSTALLED_APPS constant in a top-level "settings" package. This makes using parts of Django in scripts a PITA, as your script needs an accompanying settings file. Also, apps are not properly defined either and in some instances an app must have a "models" subpackage (or at least this used to be the case).

I thought the general solution to this was just to create a /tests directory and stuff everything in there, broken out as you wish?

Did I just make that up?

No that's basically how everyone does it. Same thing for models, views, etc. It's all python.

You could ask for a refund. :) Otherwise you just might have to figure out how to do it yourself. That is how the world works fundamentally. You're actually lucky you're getting Django for free, providing so much functionality out-of-the-box. TANSTAAFL.

Reply on news.ycombinator.com