On Nov 15, 7:19 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> Thanks for bringing this topic up for discussion.
>
> > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> > able to implement even part of the wanted features. The app cache
> > needs a thourough look. But I don't see installing apps multiple times
> > as a favored feature. I will happily participate in any work on this."
>
> > Well, what are those features you wanted, explicitly?
>
> Mostly what has been written down
> athttp://code.djangoproject.com/wiki/InstalledAppsRevision
Thank you for your response. If you mean
* Allow change of name of third-party app
* Allow change of db_prefix of third-party app
* Allow multiple instances of an app with different names,
db_prefix, etc.
> .
>
> Using an app multiple times is pretty difficult since it requires
> changes in the way the models are registered. To be honest, I'm not
> sure what the use case is for that. Could someone give an example
> please?
>
I'm not sure there is a particularly good case for worrying
excessively about multiple instances of the same app, as it's hardly
the common case. Are not the first two of the three goals sufficient
justification? Given that there is an ever-increasing body of
applications out there, the chances of a name clash in the label is
also ever-increasing. AFAIK, the #3591 patch meets the first two
goals, assuming that by "name of third-party app" you mean a verbose
name which can be e.g. internationalised. I would rather not bang on
about the multiple-instances-of-the-same-app case because it would be
a side benefit rather than a benefit which would be widely enjoyed.
>
> Yes, I tried it but wasn't convinced of how it's bound to the
> settings. In my (indeed unfinished) try I refactored the AppCache to
> live in django.core.apps that would contain instances of the new
> django.core.apps.base.App base class, each representing an app entity.
> The model loading mechanism would then use the app instances to get a
> list of available models, instead of the global model registry Django
> has now. Moving the app definition out of the settings.py would also
> allow i18n and all the other wonderful benefits class inheritance
> brings.
I'm not quite sure what you mean by "wasn't convinced of how it's
bound to the settings." Did it work, in the sense that you could
disambiguate apps and apply verbose names to them? In my
implementation, I went for minimal changes to the Django source,
because I thought it would make it easier for people to scan,
understand, review and hopefully accept the changes. If the basic
premise of an app class - instances of which can live in
settings.INSTALLED_APPS - is acceptable (and, of course, this means
instances of subclasses of app can live in settings.INSTALLED_APPS
too) then the precise location of an implementation (e.g.
django.core.apps) can be refined. Also, the functionality of that app
class (the base class) can be enhanced over time. What's important as
the first step is to have a place to hang your hat when talking about
an app instance in a Django site.
> Users would be able to subclass the django.core.apps.base.App to use
> hooks for app-level testing, signal registration, database prefixes
> and verbose names. INSTALLED_APPS could then be a list of: a) a Python
> path to that app class or b) a path to a Python module, e.g.:
>
> INSTALLED_APPS = (
> 'django.contrib.admin',
> 'tagging.app.TaggingApp',
> 'registration',
> )
>
> Those items in INSTALLED_APPS that aren't paths to App subclasses
> would prompt the AppCache to create App instances on runtime by using
> the base class -- much like the admin does it now with ModelAdmin
> classes.
>
> Additional (and future) use cases could be inter-app dependencies and
> compatibility with the WSGI app standard -- although I understand
> that's very much debatable.
>
Previous objections by the committers have been about the apparent
complexity of proposed changes, and I have tried to keep the design/
implementation as minimal as possible in deference to these worries.
However, the approach allows app-centric functionality to be refined
over time, and I can't see any specific problems with the current
approach which would hamper this refinement. I believe your idea of
using app class names in INSTALLED_APPS is weaker than using app class
instances because it does not allow you to parametrise entries in the
simplest possible way. For example, if I have a couple of third-
party applications whose package paths end in 'auth' and 'comments',
and I want to also use 'django.contrib.auth' and
'django.contrib.comments' on my site, then I have a problem with
app_labels 'auth' and 'comments'. With app instances in the mix, I can
do for example
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.comments',
...
app('third.party.app1.package.path.ends.in.auth', 'tp_auth'),
app('third.party.app2.package.path.ends.in.comments',
'tp_comments'),
...
)
This is not possible if I am putting in the name of an app class.
However, if you want to have specific app classes, then you can import
them into settings.py and have entries such as
from my.package import MyCustomAppSubclass
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.comments',
...
app('third.party.app1.package.path.ends.in.auth', 'tp_auth'),
app('third.party.app2.package.path.ends.in.comments',
'tp_comments'),
MyCustomAppSubclass('path.to.my.app', 'my_app_label', 'other
parameters'),
...
)
Having app as a callable rather than a class also provides
flexibility, which is why I have used the lower-case name.
Bottom line: the need to "fix app_label" (i.e. disambiguate different
apps which, with the current implementation, will be assigned the same
label) keeps coming up from time to time, as evidenced by this thread
of Jacob's in December 2007:
http://groups.google.com/group/django-developers/browse_thread/thread/d1eca0f5dca49a07/0abbfc55f8421456
I guess the requirement in that instance went away, or was resolved in
some other way which didn't involve changing Django. However, I think
that the need to disambiguate third party apps is important, and the
#3591 patch fills that need without being overly ambitious in its
scope to try and shoe-horn other stuff in. So if we leave aside the
multiple-instances-of-the-same-app case, I believe that the #3591
patch meets the requirements (goals) outlined in
http://code.djangoproject.com/wiki/InstalledAppsRevision
BTW, I also think it's worth separating the discussion about the
developer interface - i.e. what settings.INSTALLED_APPS might look
like, what the app class looks like (or whether it should be specified
as just a callable) and additions to the API such as find_app() and
get_installed_app_paths() - from the specifics of the implementation
(e.g. should the code live in django.core.apps).
Best regards,
Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
