[Django] #28367: howto handle different apps with same custom management command names?
Django
-----------------------------------------+------------------------
Reporter: stephanm | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.11
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
Hi,
I have one question where I didn't find the answer in the docs.
If I have two django apps:
- app1
- app2
and both apps have lets say a custom management command called:
- importdata
Actually I do the following:
In every app I prepend the custom command name with the app name,
so in my case the custom commands would be named:
- app1_importdata (for app1)
- app2_importdata (for app2)
But what is the official "correct" way?
Does there exist some sort of namespace like:
- app1.importdata
- app2.importdata
or it is planned (in Django 2.x)?
If I have two external apps not programmed by myself
and both have one same-named management command...
how do I solve the problem?
--
Ticket URL: <https://code.djangoproject.com/ticket/28367>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
--------------------------------------+------------------------------------
Reporter: stephanm | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
* component: Uncategorized => Documentation
Comment:
You need to use unique command names -- there's no notion of namespacing,
though this was suggested in #27189, I don't think there was an follow up
on that idea.
I'll classify this as a documentation ticket for explaining how to
override management commands. There's a brief discussion
[https://stackoverflow.com/questions/29320103/if-multiple-django-apps-
define-the-same-custom-management-command-which-is-used on StackOverflow]
which could be a useful starting point in writing some docs.
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:1>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by stephanm):
OK, so I did the right thing in my projects.
But one question remains:
What should I do if some day I need a django app
from pypi which has the same management commands?
(... or more than one django app from pypi where
all of them have management command names collisions)
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:2>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
You could alias the overridden command by creating a new management
command in your project and importing the overridden command there so that
it's accessible under a different name.
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:3>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: assigned
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Jkrzy):
* owner: nobody => Jkrzy
* status: new => assigned
Comment:
I'll update the documentation to detail current behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:4>
Django
--------------------------------------+------------------------------------
Reporter: stephanm | Owner: Jkrzy
Type: Cleanup/optimization | Status: assigned
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Jkrzy):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:5>
Django
Reporter: stephanm | Owner: Joe
Type: | Krzystan
Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"48d92fea672928b4571ddaab03667e74671391c0" 48d92fe]:
{{{
#!CommitTicketReference repository=""
revision="48d92fea672928b4571ddaab03667e74671391c0"
Fixed #28367 -- Doc'd how to override management commands.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: stephanm | Owner: Joe
Type: | Krzystan
Cleanup/optimization | Status: closed
Component: Documentation | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"f9db06cf0812ee017b34bc786e1bf96e40f2327b" f9db06cf]:
{{{
#!CommitTicketReference repository=""
revision="f9db06cf0812ee017b34bc786e1bf96e40f2327b"
[1.11.x] Fixed #28367 -- Doc'd how to override management commands.
Backport of 48d92fea672928b4571ddaab03667e74671391c0 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28367#comment:7>