Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5369 closed (fixed)

Allow commands to register their own options (and refactor help to reflect this)

Reported by: toddobryan@… Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Keywords: command
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by adrian)

After the refactoring of, 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. --option command must now be written as command --option.

Attachments (1)

command.patch (21.0 KB) - added by toddobryan@… 7 years ago.
patch implementing the refactoring

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by toddobryan@…

patch implementing the refactoring

comment:1 Changed 7 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

This is looking good -- thanks for your work on this, Todd! I'm reviewing the patch now.

comment:2 Changed 7 years ago by adrian

  • Description modified (diff)

Fixed formatting in description.

comment:3 Changed 7 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

(In [6075]) Fixed #5369 -- Refactored the help system, allowing each subcommand to register its own options. Thanks for the patch, Todd O'Bryan

comment:4 Changed 7 years ago by adrian

A quick note on the patch: The method of looking at superclasses for different option_list values seemed a bit strange, so I changed it to make each class responsible to set option_list "from scratch" (by appending to its superclass' value.

comment:5 Changed 7 years ago by adrian

Also, I added special-case code for --version and --help -- those are too well-known (and standard) to have lost.

comment:6 follow-up: Changed 7 years ago by derelm

with that patch applied, the development server "crashes" (exiting on SystemExit(0)) instead of reloading on touching a file.

comment:7 in reply to: ↑ 6 Changed 7 years ago by tristan.king@…

Replying to derelm:

with that patch applied, the development server "crashes" (exiting on SystemExit(0)) instead of reloading on touching a file.

i have this same problem. i fixed it temporarily with this bit of a hack:

:django/utils$ svn diff 
---       (revision 6087)
+++       (working copy)
@@ -62,7 +62,11 @@
                 mtimes[filename] = mtime
             if mtime != mtimes[filename]:
-                sys.exit(3) # force reload
+               try:
+                   sys.exit(3) # force reload
+               except Exception:
+                   print 'sys.exit failed, trying os._exit'
+                   os._exit(3)
 def restart_with_reloader():

comment:8 Changed 7 years ago by adrian

(In [6094]) Got runserver auto-reloading working again by removing what appeared to be debugging code in Refs #5369

Note: See TracTickets for help on using tickets.
Back to Top