Opened 16 years ago
Closed 11 years ago
#11407 closed Bug (fixed)
--version weirdness
Description ¶
There's some weirdness that happens if you pass both --version and a subcommand, or another option, to manage.py (or django-admin.py):
kmt@lbox:~/software/web/playground$ ./manage.py --version --help 1.1 beta 1 SVN-11115 Unknown command: '--version' Type 'manage.py help' for usage. kmt@lbox:~/software/web/playground$ ./manage.py runserver --version 1.1 beta 1 SVN-11115 1.1 beta 1 SVN-11115 kmt@lbox:~/software/web/playground$ ./manage.py test --version 1.1 beta 1 SVN-11115 1.1 beta 1 SVN-11115 kmt@lbox:~/software/web/playground$ ./manage.py lskdjfljtest --version 1.1 beta 1 SVN-11115 Unknown command: 'lskdjfljtest' Type 'manage.py help' for usage. kmt@lbox:~/software/web/playground$
--version
as provided by optparse.OptionParser
is documented to print the version string and exit. This is done when parse_args
is called. However the LaxOptionParser
defined and used within django.core.management.__init__
overrides _process_args
so that the SystemExit raised when --version
is processed is swallowed/ignored. Thus the version gets printed but the program does not exit but rather proceeds. Things then may get a little confused depending on what else has been specified on the command line. In the case of no subcommand the --version argument is attempted to be interpreted as a subcommand. In the case of a valid subcommand being specified, a regular OptionParser
is called to process the arguments for it, and that one will again print the version string but then actually exit. In the case of an invalid subcommand, you'll get a message to that effect. This last one actually looks like reasonable behavior but the others are a bit confusing, so it would probably be better if the program did consistently exit on the first processing of --version
, ignoring whatever else may have been specified.
Change History (12)
comment:1 by , 16 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:3 by , 13 years ago
Easy pickings: | unset |
---|---|
Owner: | changed from | to
Status: | new → assigned |
UI/UX: | unset |
by , 13 years ago
Attachment: | command_parser.diff added |
---|
comment:4 by , 13 years ago
comment:5 by , 13 years ago
Has patch: | set |
---|
comment:6 by , 13 years ago
Patch needs improvement: | set |
---|
This breaks the admin_scripts tests currently.
by , 12 years ago
Attachment: | 11407-2.diff added |
---|
comment:7 by , 12 years ago
Owner: | removed |
---|---|
Patch needs improvement: | unset |
Status: | assigned → new |
Just uploaded a new patch. It's somewhat similar to the one marclurr posted, except I didn't rename the subclassed parser. All tests pass with sqlite3.
comment:8 by , 11 years ago
Keywords: | management django-admin.py manage.py added |
---|
comment:9 by , 11 years ago
After the partial rewrite needed by the conversion to argparse
(#19973), only the first "weirdness" partially subsists:
$ ./manage.py --version --help Unknown command: '--version' Type 'manage.py help' for usage.
or
$ ./manage.py --help --version Unknown command: '--help' Type 'manage.py help' for usage.
While individually using --help
or --version
produces the expected output. Do we want to specifically support that sort of combination?
comment:10 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
That wouldn't be a good use of your time. I don't see the use case for asking for both help and version at the same time.
Explanation of changes in command_parser.diff: