Make the implications of order in INSTALLED_APPS more consistent

[Kevin Christopher Henry]

There are several subsystems that are affected by the order of the apps in INSTALLED_APPS. These include (at least): templates, static files, translations, and management commands. For the first three, the rule is that the first listed app has precedence: it will be used in preference to any app listed later that uses the same name for something (e.g. a template, file, or translation).

In the case of management commands, however, the semantics are just the opposite: precedence is given to apps that are listed later.

The proposal is to fix this so that management commands follow the same ordering rules as the other subsystems. This is an easy fix, but it has implications for backwards compatibility: specifically, for any project that currently has two apps in INSTALLED_APPS that define the same command, the one that is actually used will change. (Note that this does not apply to the case of apps overriding core management commands; they will continue to do so.)

See ​here for a discussion of the issue.

See #20914 for a proposal to document more thoroughly the issue of order in INSTALLED_APPS.

[Russell Keith-Magee]

Although it isn't obvious, this looks to me to be a duplicate of #3591 (or, at the very least, an issue that should be considered as part of that work). This ticket is the placeholder for the "app refactor", which resolves a bunch of issues related to the startup sequence and application loading.

[Carl Meyer]

Is it useful to close every ticket related to INSTALLED_APPS handling as a duplicate of #3591? #3591 is already a massive bite to chew, which is a large part of why the work on that ticket has not been merged yet (and AFAICT it's not entirely clear if or when it will be.) If anything, #3591 could really benefit from a reduction and clarification of scope, not a creeping scope that encompasses everything about apps.

Fixing this ticket, if we decide to fix it, is a simple code change; I don't see how it requires or benefits from being lumped in with #3591. It's certainly not in any way a duplicate of the original motivating feature request in #3591. If it happens to be also fixed by a hypothetical eventual fix for #3591, great, but it's a separate issue.

All else being equal, "more smaller tickets handled independently" is superior to "fewer big tickets".

[Kevin Christopher Henry]

If this is something that should be changed, I would tend to agree with Carl. It's a simple change (one line of code?), and shouldn't hinder any of the work in #3591, so why not do it right away? Especially since this behavior hasn't been, but should be, and is about to be, documented, it would be nice to be able to say the right thing.

If the question of whether or not to change it is complicated and needs to be considered in light of the work being done in #3591, then I suppose it makes sense to merge it into that issue.

[Marc Tamlyn]

I agree with Carl as well. Whilst this may be covered by app-refactor, it's also a distinct issue in and of itself, which behaves in a counterintuitive manner.

[Shai Berger]

The correct fix, IMO, is not one line of code, but a way for the "conflicting" apps to interact.

While this probably doesn't make sense for templates, static files, or translations, many overridden management commands end up being additions, or wrappers, to the commands they override. If you have a painter app and a gunman app both defining a new command draw, then there's no useful interaction, but if you have both django_extensions and django_other_extensions extending runserver, then it makes sense for each of them to "call up" -- and they may just work together well.

Another idea is to allow a general mechanism of command aliasing -- say, a setting

COMMAND_ALIASES = {
   'run1' : 'app1.runserver',
   'run2' : 'app2.runserver',
}

Which would take precedence over the INSTALLED_APPS order; then a user could set runserver='my.runserver' to keep the one they like.

(one can easily get carried away and add default command arguments into the alias, but that would belong in a completely different ticket).

[Aymeric Augustin]

Regardless of the merits of a generic inheritance, extensibility or namespacing mechanism, it shouldn't stop us from fixing inconsistencies. And even if we create such a mechanism, it will still be a good idea to have consistent defaults.

Are you really opposed to fixing the inconsistency reported here until we have a "correct fix", whatever that is?

[Aymeric Augustin]

#21527 is a subset of this ticket.

[Aymeric Augustin]

The patch for #3591 doesn't address this, but it guarantees that apps.get_app_configs() honors the order of settings.INSTALLED_APPS.

[Aymeric Augustin]

Since there's no test for the current order, no significant opposition to the change, and no suitable deprecation path, I'm going to proceed with this change.

I find "last app wins" more intuitive that "first app wins" but since it's more backwards compatible to standardize on "first app wins" let's do that.

---

Replying to marfire:

It's a simple change (one line of code?)

I'll let you look at the 100 + 125 lines of diff for the two commits that fixed this issue and figure out why I ended up two orders of magnitude above your estimate. :-)

[Aymeric Augustin <aymeric.augustin@…>]

In f17d00278ee4a22421dc8148588d94fe7fa17427:

Wiped get_commands() cache when INSTALLED_APPS changes.

Refs #21018, #21688.

[Aymeric Augustin <aymeric.augustin@…>]

In 0ce945a67151acf2c58bc35a47f4c3d45ff30085:

Fixed #21018 -- Reversed precedence order for management commands.