Django

Code

Ticket #5369 (closed: fixed)

Opened 1 year ago

Last modified 1 year ago

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

Reported by: toddobryan@mac.com Assigned to: nobody
Milestone: Component: django-admin.py
Version: SVN Keywords: command
Cc: Triage Stage: Unreviewed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description (Last modified by adrian)

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.

Attachments

command.patch (21.0 kB) - added by toddobryan@mac.com on 09/08/07 21:52:30.
patch implementing the refactoring

Change History

09/08/07 21:52:30 changed by toddobryan@mac.com

  • attachment command.patch added.

patch implementing the refactoring

09/09/07 15:27:33 changed by adrian

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

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

09/09/07 15:32:28 changed by adrian

  • description changed.

Fixed formatting in description.

09/09/07 16:57:59 changed by adrian

  • status changed from new to closed.
  • resolution set to fixed.

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

09/09/07 17:13:18 changed 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.

09/09/07 17:15:35 changed by adrian

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

(follow-up: ↓ 7 ) 09/10/07 03:59:25 changed by derelm

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

(in reply to: ↑ 6 ) 09/10/07 21:09:40 changed by tristan.king@jcu.edu.au

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 autoreload.py 
Index: autoreload.py
===================================================================
--- autoreload.py       (revision 6087)
+++ autoreload.py       (working copy)
@@ -62,7 +62,11 @@
                 mtimes[filename] = mtime
                 continue
             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)
         time.sleep(1)
 
 def restart_with_reloader():

09/10/07 23:37:23 changed by adrian

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

Add/Change #5369 (Allow commands to register their own options (and refactor help to reflect this))




Change Properties
Action