On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> In implementing the "manage.py testserver" command, I've been struck
> by how large django/core/management.py has gotten. It's 1730 lines
> long -- and messy.
>
> I'd like to split this into several files, turning
> django.core.management into a package.
As of changeset [5898], I've checked in this refactoring. Here's a
quick overview of the new design:
* django/core/management is now a package.
* django/core/management/commands is a package in which each module is
a django-admin.py command -- "syncdb.py", "runserver.py", etc. To add
or remove commands, just add/delete the modules in there; there's
nothing else to do (with one exception, which I'll bring up in a bit).
* Each command is a subclass of
django.core.management.base.BaseCommand. Each subclass is required to
implement a handle() method, which is passed the command-line
arguments as *args and the command-line options as **kwargs. These
subclasses also define "help" and "args" attributes, which are used in
the "django-admin.py --help" usage text.
* Some of the commands use a different parent class, AppCommand, which
takes care of some model-related functionality. In this case, the
subclasses are required to implement handle_app(), not handle().
* It would be nice if each Command knew which options it took -- e.g.,
the "shell" command takes the optional "--plain" command. I originally
implemented this but ran into the problem that the optparse module
doesn't allow the registration of multiple options with the same name,
which means we'd have to keep track of which options had already been
registered, and what do we do in the case of conflicts, etc. I just
decided to skip over this for now, just to get the refactoring done.
So if/when we add new django-admin commands that require new options,
we'll have to remember to add them to ManagementUtility.execute() in
django/core/management/__init__.py.
* There's a new API for calling commands directly: use
django.core.management.call_command(). Examples:
call_command('syncdb')
call_command('shell', plain=True)
call_command('sqlall', 'myapp', pythonpath='/foo/')
* This is backwards incompatible for any code that relied on the
various django.core.management functions. One notable exception to
this (i.e., a backwards *compatibility*) is that
django.core.management.execute_manager still exists -- because every
manage.py file out there relies on this function.
* I have tried to iron out all the bugs I could find (and there were a
lot, as this was quite a big refactoring!), but I'm sure I missed
some. Please poke around and speak up if there are any errors. Two
outstanding issues are that the "syncdb" command displays far more
verbose data than it did before, and a few of the unit tests are
failing (due to an output-formatting issue). I'm off to bed but will
be back at this tomorrow in case of problems. Django committers Down
Under, feel free to chip in, if you'd like.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
