I'm on a quest to simplify Django's default project layout even more.
Right now, "django-admin.py startapp" creates a "models" directory
within the app directory -- and, in fact, it's required by Django that
models live in a "models" directory within a package pointed-to by
INSTALLED_APPS.

Here's an idea rjwittams and I were discussing the other night in IRC:

* Change Django so that it looks for models in a "models" package (as
it currently does) *or* in a file called models.py. Either the models
package or models.py should live directly within the package
pointed-to by INSTALLED_APPS.

* Change "django-admin.py startapp" so that it creates a models.py
file instead of a models package with __init__.py and appname.py in
it.

* Change django-admin.py so that the various commands that act on apps
-- such as sql, install and sqlreset -- take the *full app name* (e.g.
"myproject.polls") instead of the name of the Python module that holds
the models. This would have the following subtle side effect:
Currently, in the following example app layout...

    myapp/
        models/
            __init__.py
            foos.py
            bars.py

...the developer has to run two commands -- "django-admin.py install
foos" and "django-admin.py install bars" -- to install the database
tables for this app. With the proposed change, the developer would
only have to run "django-admin.py install myapp", and it'd install
both.

The only problem with installing both via a single command is that the
models might have dependencies on one another and might have to be
installed in a certain order. Maybe django-admin could just use the
order in models.__init__.__all__ for that.

The main advantage of the models.py solution is it's less complexity
(fewer files to juggle), and the file is called models.py instead of
(in the tutorial's example) polls.py. The fewer files named polls.py,
the better.

People would still be free to create a "models" subpackage that would
contain models in multiple files. Django would use all models
pointed-to by the "__all__" variable in the __init__.py, as it does
now.

Thoughts?

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

Reply via email to