Adrian Holovaty wrote:
> * 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. +1 > * 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. 0; you don't do this step very often. > 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. this moves me to say -1. Either automate the dependency management issue or punt. Halfway houses will have 'unpredictable' consequences :) > 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. That's my main day to day annoyance with Django - the "which file is it" game. On the other hand with a models.py file the domain will get lumped into a single file. Having the option to break out classes into multiple files gives you a path to factor out to standalone apps as and when. So despite "the one way to do it" mantra, I think you need to provide both options. > 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? Sounds good. It'll make starting out with Django easier. cheers Bill
