#29301: Reorder management command arguments in --help output to prioritize
command-specific arguments
-------------------------------------+-------------------------------------
Reporter: David Foster | Owner: David
Type: | Foster
Cleanup/optimization | Status: new
Component: Core (Management | Version: 2.0
commands) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by David Foster):
> If a third-party app adds one of the default arguments in the
.add_argument() function, django now fails trying to re-add the argument.
What would be the desired outcome in case of a conflict?
(A) If we take the interpretation that the Django framework "owns" the
default arguments then the conflict should cause a failure. Adding new
default arguments would then be a backward-incompatible change. This is
the current state now that the original patch is merged.
(B) If we take the interpretation that management commands are ultimately
in control of their arguments, I would expect Django to back off if sees
that a management command added its own argument with a conflicting name.
Adding new default arguments would then be a minor change.
Before the original patch for this ticket was merged, add_arguments() was
allowed even more leeway than (B), potentially removing default arguments
outright, setting a custom formatters, or doing other unusual things, even
though those possibilities were not documented. I don't think we should
necessary support arbitrary actions in add_arguments().
I'm personally +0 on approach (B). It would involve a small additional
patch where Django checks whether each default argument already existed
before adding its own.
---
Claude, I'm resistant to introduce a custom formatter here that
reinterprets the argument order at format time, as it feels relatively
complex and overrides the default behavior in a potentially unexpected
way. We also have to duplicate the list of default arguments in multiple
places which smells like a design issue.
As a minor point, adding a custom formatter in Django would probably break
any custom formatter added by preexisting management commands, such as in
add_arguments(). Adding a custom formatter feels like an odd thing for a
management command to do and we don't suggest doing that in our
documentation, but it's possible that certain advanced third party
commands may do it anyway. They then don't benefit from the argument
reordering change, under the assumption that the per-command custom
formatter would clobber the Django custom formatter.
--
Ticket URL: <https://code.djangoproject.com/ticket/29301#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.27655040faf688c14d30539d11fe7713%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.