Opened 17 years ago
Last modified 17 years ago
#5369 closed
Allow commands to register their own options (and refactor help to reflect this) — at Version 2
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Core (Management commands) | Version: | dev |
| Severity: | Keywords: | command | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
After the refactoring of django.core.management, it was clear that having one universal set of options was less elegant than allowing each command to register just those options it allows. This refactoring keeps exactly the same functionality, but separates out the options. Any subclass of BaseCommand can provide its own option_list (with each option created using optparse.make_option). It inherits all the options in its class hierarchy. (One caveat: BaseCommand subclasses can only extend one superclass. I think handling multiple inheritance is possible, but I'm not sure how much harder it would be and can't think of a reasonable use case that would require it.)
There is a slight backwards incompatibility. django-admin.py --option command must now be written as django-admin.py command --option.
Change History (3)
by , 17 years ago
| Attachment: | command.patch added |
|---|
comment:1 by , 17 years ago
This is looking good -- thanks for your work on this, Todd! I'm reviewing the patch now.
patch implementing the refactoring