Order of includes in root urls.py

[KenWhitesell]

The order does matter - especially where regex paths are concerned.

But first, you ask:

@ehmatthes

Is there a URL that should match the synths app in the above root urls.py, but gets grabbed by the pianos include() call, that would be fixed by moving the pianos include() call to the last position?

I guess it depends upon what you mean by “fix”.

A url will only dispatch to one view - and it will dispach to the first view matching the url pattern.

You answered that above when you said:

@ehmatthes

and puts a pattern like path("synths/.../") in pianos/urls.py. That could certainly duplicate a URL that already exists in the synths app. But moving the pianos include() call to the last position in the root urls.py wouldn’t fix that.

So it does “fix” that, in that those urls would now be handled by synths.urls and not by pianos.urls.

It’s up to you to decide which of those modules will handle /synths/yamaha/mx88bk.

@ehmatthes

So in this scenario the real problem is a lack of coordination between apps about maintaining unique URL paths, not the order of includes in the root urls.py, right?

That is correct.

@ehmatthes

Is it a best practice not to have any app match the empty string in the root urls.py, even it it’s the main app in the project?

That’s an architectural decision. In general, I would say it’s not best practice to not have it. Or, to attempt to untorture that sentence by removing the double negative - I believe it’s a best practice to have it. You likely still want to have the empty string to map it to a “home” page. I just don’t suggest mapping the empty string to an included url module.