Management commands are collected in the wrong order

[Klaas van Schelven]

When multiple management commands of the same name exist, the ones found in apps higher in the INSTALLED_APPS should get precedence; right now, it's reversed.

This is completely analogous to the problem described (and fixed) in
https://code.djangoproject.com/ticket/14924
One could basically read that ticket and replace "translations" by "management commands".

In this case, the relevant update statement may be found below:
https://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py?rev=16222#L117

I'm awfully sorry, don't have the time now to submit a patch. My thoughts would be: either run through the apps in reversed direction, or don't work with an update statement, but rather only add values to the dict if they're not present yet.
The previous, analogous solution is indeed based on 'reversed' and may be found here:
https://code.djangoproject.com/changeset/15441#file2

[Aymeric Augustin]

Revert spam :(

[Klaas van Schelven]

Bewgh... the spam also marked this as "fixed"

[Aymeric Augustin]

I'm afraid reversing the order is backwards incompatible. It could cause a wrong command to be executed after an update of Django, with unexpected consequences (read : data loss).

However, it makes sense to have the same order for management commands, templates, translations, and anything else that can be overridden. Otherwise, for instance, it's impossible for an app to override a command and a template of a contrib app.

[anonymous]

Actually, we've never promised anything about the order of evens in INSTALLED_APPS - the documentation's careful to indicate that the order ought to be considered an implementation detail, not an API. Given that, I'm going to mark this wontfix.

However, there's a very real need here for a consistant, accurate, bulletproof way to override management commands. A new ticket regarding that would be most welcome (especially if it has good ideas!)

Thanks!

[Jacob]

Oops, that was me. Sorry.

[Russell Keith-Magee]

As a side note, the proposed behavior would actually break a bunch of really useful features, including the way that static media is served by the runserver.