Revisiting 'apps with the same name'

[Dan Ellis]

Originally discussed in this 2006 thread, which is no longer open for
replies:
http://groups.google.com/group/django-developers/browse_thread/thread/7197d27127494ee2

I noticed this thread after following the link from the ticket
(#3591), and I'm a little concerned about the direction the ticket has
taken, as it seems to be over-engineering the solution somewhat. I
think a far better solution is to, wherever possible, keep the
application name as the Python package name used in INSTALLED_APPS
instead of trimming it. They're already fully qualified, and if two
Python package names clash they aren't going to work together
regardless of what Django does.

Joseph Kocherhans wrote:

> Admin urls are now like /admin/mypackage/myapp/mymodel
> rather than just /admin/myapp/mymodel.

and:

> Breadcrumbs and admin urls were a lot less complicated before the change.

This particular problem can easily be solved by using a URL like /
admin/mypackage.myapp/mymodel. There isn't any need to split the
application's Python package name up and convert dots to slashes.

> If I run:
> ./manage sql auth (or any other command that takes app_label as the first arg)
> I get the sql for the first auth app that appears in INSTALLED_APPS.
> AFAICT it's impossible to install the second app without switching
> their order in settings.py. That's simply not acceptable.

Solution: have manage take fully-qualified package names as the
application argument.
./manage sql django.contrib.auth

> I imagine there's a similar problem with the filesystem template loader.

Similarly, templates can be in directories like templates/
mypackage.myapp/...

> Table names are still just appname_modelname. Of course you can use
> 'db_table' to fix the issue, but it seems like something that should
> "just work (tm)" I don't really like the idea of prefixing the package
> name, but I don't see any other obvious options. Ideas?

I agree that this is more difficult problem, but a different problem
in that in many cases the database table name prefixes don't need to
be exposed to the user. One thing is certain, table names with dots in
won't work. Table names like django_contrib_auth_user are a little bit
unwieldy, but are valid, fully qualified (so no clashes) and clearly
identify which tables are django's own. (Of course, that's just the
default; there's still db_name for those who need it.)

> Any ideas that don't involve 50+ character table names and 10 level
> deep template directories? ;-)

Well, my idea certainly means that template directory hierarchies are
no deeper than with simple app names, and it means no manual 'tagging'
of app names in INSTALLED_APPS.

[Vinay Sajip]

On Sep 15, 4:59 pm, Dan Ellis <d...@remember.this.name> wrote:
> Originally discussed in this 2006 thread, which is no longer open for

> replies:http://groups.google.com/group/django-developers/browse_thread/thread...

>
> I noticed this thread after following the link from the ticket
> (#3591), and I'm a little concerned about the direction the ticket has
> taken, as it seems to be over-engineering the solution somewhat.

Do you mean my patch for that ticket is over-engineered? Or do you
mean that the whole idea of app instances (rather than simple app
package name strings) is over-engineered? In the same way that views
in urlconfs can be defined by strings or by callables - is one more
engineered than the other? The original impetus for the ticket came
from a wish to attach certain things to the "app" - an
internationalisable verbose name for the app in the admin, for
example. How would you propose to address this need without over-
engineering?

> think a far better solution is to, wherever possible, keep the
> application name as the Python package name used in INSTALLED_APPS
> instead of trimming it. They're already fully qualified, and if two
> Python package names clash they aren't going to work together
> regardless of what Django does.

Just to play devil's advocate, what if I wanted two instances of the
same app on a site? While this is hardly a common use case, using
fully qualified package names would prevent this, as the two instances
would have no disambiguating feature. With app instances, you can hang
disambiguating information on the app instance. Package is to app as
instance is to class, ISTM (loosely speaking, of course).

Can we be sure that all current and future backends will have no
restriction on the size of table names? Using fully qualified names
with underscores would work as long as you didn't hit some sort of
limit in this area: since package names are unrestricted as to size,
how could we be sure never to hit a limit?

Regards,

Vinay Sajip

[Dan Ellis]

On Sep 15, 5:27 pm, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:

> Do you mean my patch for that ticket is over-engineered? Or do you
> mean that the whole idea of app instances (rather than simple app
> package name strings) is over-engineered?

The whole idea proposed in the thread and the ticket.

> In the same way that views
> in urlconfs can be defined by strings or by callables - is one more
> engineered than the other?

I don't see much of a connection between that and this. Using strings
in urlconfs is a convenience for the user that helps them achieve a
DRY goal.

> The original impetus for the ticket came
> from a wish to attach certain things to the "app" - an
> internationalisable verbose name for the app in the admin, for
> example. How would you propose to address this need without over-
> engineering?

I think having verbose names for apps is a great idea, but I think the
best place for things like that is in the application itself -- that
is, within the namespace declared in INSTALLED_APPS. I notice that
another post in this group suggested Application objects, and I think
that's a great idea too. So, for an application pkg.app you could
either have a pkg.app.Application class that Django instantiates when
the application is loaded, or a pkg.app.application that is already
instantiated. That would gather together information about the
application as suggested in that post.

> Just to play devil's advocate, what if I wanted two instances of the
> same app on a site?

Can you give an example of when you might want that? There's no reason
that applications can't themselves support multiple instances of
whatever feature they provide -- a table of blogs, or a table of
forums, for example. I'm still thinking about this one.

> Can we be sure that all current and future backends will have no
> restriction on the size of table names?

No, and I don't know what the current length restrictions are.
Probably the only thing we can assume is that the limits for existing
backends won't go down from whatever they are now if those RDBMS
vendors care about backwards compatibility.

> Using fully qualified names
> with underscores would work as long as you didn't hit some sort of
> limit in this area: since package names are unrestricted as to size,
> how could we be sure never to hit a limit?

You're absolutely right about this, but I think it's a separate
problem, one at the ORM level in the same way that db_name is. In case
this ever happened, we could have a DATABASE_PREFIXES variable in the
settings file that would normally never need to be set. It would just
look like {'some.long.name.for.a.blog.app.package': 'blog'}.