Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9715 closed (invalid)

r9110 introduced Backwards-Incompatible change

Reported by: Marc Fargas Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


From api-stability: "code you develop against Django 1.0 will continue to work against 1.1 unchanged"

Since r9110 the --verbosity parameter is now defined which means that any custom command defining this parameter will fail miserably:

Traceback (most recent call last):
  File "./", line 17, in <module>
  File "/home/marc/dev/python/django/django/core/management/", line 340, in execute_manager
  File "/home/marc/dev/python/django/django/core/management/", line 295, in execute
  File "/home/marc/dev/python/django/django/core/management/", line 192, in run_from_argv
    parser = self.create_parser(argv[0], argv[1])
  File "/home/marc/dev/python/django/django/core/management/", line 175, in create_parser
  File "/usr/lib/python2.5/", line 1215, in __init__
  File "/usr/lib/python2.5/", line 1257, in _populate_option_list
  File "/usr/lib/python2.5/", line 1040, in add_options
  File "/usr/lib/python2.5/", line 1021, in add_option
  File "/usr/lib/python2.5/", line 996, in _check_conflict
optparse.OptionConflictError: option --verbosity: conflicting option string(s): --verbosity

That happens because the command I tried to execute had a custom --verbosity option.

Change History (3)

comment:1 Changed 10 years ago by Malcolm Tredinnick

Resolution: invalid
Status: newclosed

You are only quoting selectively from that document. That is an area that was not guaranteed to be stable. The document is talking about the public API and then goes on to list precisely what that means. Notice that management commands are not included in that list. We aren't going to make arbitrary changes to screw people up, but doing things like refactoring the code to make a common option available to everything (adding functionality) is always possible.

If what you're asking for was to hold true, we could never, ever add a method to a model (it might clash with something somebody already has), or introduce a new module into Django (it might clash with something somebody already has), or change a string (somebody's code might be depending on the string value), or update translations (somebody's code might be depending on the string not being translated). We have to be able to make expansions. That is why we went to some lengths to document what is considered stable.

Sorry that it clashed with a local change you made, but it really can't be helped.

comment:2 Changed 10 years ago by Russell Keith-Magee

If the issue is maintaining source code compatibility with both trunk (which has the change) and v1.0.X (which doesn't), there is a solution - check whether --verbosity is available as an option before adding it. The following code will allow you to maintain a single code base, but support both branches:

class Command(BaseCommand):
    option_list = BaseCommand.option_list + (
        make_option('--blah', action='store_false', dest='blah', default=True),
    if '--verbosity' not in [opt.get_opt_string() for opt in BaseCommand.option_list]:
        option_list += make_option('-v','--verbosity', action='store', dest='verbosity', default='1',
            type='choice', choices=['0', '1', '2'],
            help='Verbosity level; 0=minimal output, 1=normal output, 2=all output'),

comment:3 in reply to:  1 Changed 10 years ago by Marc Fargas

Replying to mtredinnick:

Sorry that it clashed with a local change you made, but it really can't be helped.

Np, I do not care that much. But there may be a big a big bold note in the 1.1 release notes saying "If you have a --verbosity parameter in a custom management command it will break" ;)

Thanks for the comments on api-stability to both of you! ;)

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