7 ms·

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 bu

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.

philipkimmey 15y ago
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.
- nicpottier 15y ago
  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?
  - 2mur 15y ago
    No that's basically how everyone does it. Same thing for models, views, etc. It's all python.
- bad_user 15y ago
  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).
mazzer 15y ago
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.)
mkramlich 15y ago
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.
oinopion 15y ago
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
- LeafStorm 15y ago
  ...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.

philipkimmey 15y ago

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.

nicpottier 15y ago
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?
- 2mur 15y ago
  No that's basically how everyone does it. Same thing for models, views, etc. It's all python.
bad_user 15y ago
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).

mazzer 15y ago

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.)

mkramlich 15y ago

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.

oinopion 15y ago

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

LeafStorm 15y ago
...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.