Namespaces declared in different places

[German M. Bravo]

Currently, if the same namespace is declared for different included urls, only one included urls module gets the namespace.

In this scenario:

urlpatterns = patterns('',
    url(r'^first/', include('first.urls')),
    url(r'^first_default/', include('first.urls', app_name='first', namespace='first')),
    url(r'^first_in_a/', include('first.urls', app_name='first', namespace='A')),
    url(r'^first_in_b/', include('first.urls', app_name='first', namespace='B')),
    url(r'^second/', include('second.urls')),
    url(r'^second_default/', include('second.urls', app_name='second', namespace='second')),
    url(r'^second_in_a/', include('second.urls', app_name='second', namespace='A')),
    url(r'^second_in_b/', include('second.urls', app_name='second', namespace='B')),
)

The expected output is:

reverse('first') -> /first/
reverse('second') -> /second/
reverse('A:first') -> /first_in_a/
reverse('A:second') -> /second_in_a/
reverse('B:first') -> /first_in_b/
reverse('B:second') -> /second_in_b/

But instead is:

reverse('first') -> /first/
reverse('second') -> /second/
reverse('A:first') -> /first_in_a/
reverse('A:second') -> NoReverseMatch
reverse('B:first') -> /first_in_b/
reverse('B:second') -> NoReverseMatch

[German M. Bravo]

Example which fails

[German M. Bravo]

Added tests (makes just two of them fail)

[Tomek Paczkowski]

Good for me.

[Paul McMillan]

Marking as a release blocker

[Aymeric Augustin]

After further discussion, this isn't really a release blocker, since it isn't a regression or a major bug in a new feature.

However, the patch looks correct and stands a good chance to be committed before 1.4.

I've spend a few hours on it, but I don't feel sufficiently familiar with the URL namespacing feature to commit it. I asked Russell (the original author) if he could take a look.

[Aymeric Augustin]

After discussion with Malcolm (the other author), this rather looks like a misuse of app_name.

This could be resolved by improving the documentation rather than changing the code.

[German M. Bravo]

I really wish this could be checked in since, even of it's a "missuse" given the original design, I believe it to be a good addition which just further increases the url resolvers code isometry and flexibly allowing the use of the same namespace name across apps... *plus* it doesn't really break anything, just covers a legit and intuitive use case for namespaces.

Any other thoughts about this ticket?

[Tim Graham]

Moving to documentation based on Aymeric's comment 22. If someone wants to lobby for a design change, please start a thread on the DevelopersMailingList.

[Tim Graham]

I think we can roll this documentation into #17707 - "Docs for URL namespaces should explain the motivation and use cases".

[Tim Graham]

It's ​documented that "Instance namespaces should be unique across your entire project." That seems to be the issue here.