r9110 introduced Backwards-Incompatible change

[Marc Fargas]

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 "./manage.py", line 17, in <module>
    execute_manager(settings)
  File "/home/marc/dev/python/django/django/core/management/__init__.py", line 340, in execute_manager
    utility.execute()
  File "/home/marc/dev/python/django/django/core/management/__init__.py", line 295, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/marc/dev/python/django/django/core/management/base.py", line 192, in run_from_argv
    parser = self.create_parser(argv[0], argv[1])
  File "/home/marc/dev/python/django/django/core/management/base.py", line 175, in create_parser
    option_list=self.option_list)
  File "/usr/lib/python2.5/optparse.py", line 1215, in __init__
    add_help=add_help_option)
  File "/usr/lib/python2.5/optparse.py", line 1257, in _populate_option_list
    self.add_options(option_list)
  File "/usr/lib/python2.5/optparse.py", line 1040, in add_options
    self.add_option(option)
  File "/usr/lib/python2.5/optparse.py", line 1021, in add_option
    self._check_conflict(option)
  File "/usr/lib/python2.5/optparse.py", line 996, in _check_conflict
    option)
optparse.OptionConflictError: option --verbosity: conflicting option string(s): --verbosity

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

[Malcolm Tredinnick]

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.

[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'),
    ...

[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! ;)