On Nov 16, 7:48 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> >>> Well, what are those features you wanted, explicitly?
>
> There was a case for multiple instances of apps when it was discussed
> at the Pycon sprint and I just forgot it.
>
Ok - I'm not saying there's no case for it, just that it is a rare
case and so appropriate weighting should be given to it.
> I mean with that sentence: I don't like the current implementation
> because it extends the settings system when it really should have its
> own place. I doubt for example that translated verbose_name arguments
> would work -- just like it doesn't work for the LANGUAGES setting
> where a dummy gettext function is needed to prevent a recursive
> import. And that's just one example why it makes sense to put app
> class definitions outside the settings.
>
> It's not a matter of the amount of changes, as far as I understand it.
> The app handling is a sensitive topic that deserves more than a fast
> fix (yes, I know the ticket is old).
>
I agree with you that django.conf is not the best place for the app
class to live, and the implementation is not like it is because of
wanting a fast fix. As you point out, the ticket and the patch are
pretty old. If the core developers say the basic idea is fine, and to
refactor it into e.g. django.core.apps, I'll get on it right away. But
up till now there's been absolutely no review from the core devs or
anyone else where specific points like the one you bring up have been
made; I've been waiting a long time for any specific comments at all,
so thanks for those.
> > 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.
>
> I'd also love to hear something from the core devs on that.
Yep, let's see what they say. Malcolm has already voted -1, so does
this mean it's not going ahead for 1.1? According to Jacob's original
post, this would be killed now. But Malcolm has not given any specific
criticisms of the patch, and spoken only in generalities. And Jacob
asked me in private mail to start this thread, to which he expects to
contribute.
>
> Your patch adds app classes to the settings system while apps aren't
> just a matter of setting things up.
>
Sure, and I'd be fine with putting app-related stuff in e.g.
django.core.apps and importing those into settings.py. I see that as a
minor refactoring issue. The placement of the app class in the conf
system was pragmatic, to see if the idea would fly. No core dev ever
commented on this patch, so it stayed as it was.
>
> Having app instances in settings.py is in sharp contrast to how the
> settings.py is used currently. Extensible features like
> AUTHENTICATION_BACKENDS, FILE_UPLOAD_HANDLERS, MIDDLEWARE_CLASSES,
> SESSION_ENGINE, TEMPLATE_CONTEXT_PROCESSORS and TEMPLATE_LOADERS all
> use tuples containing paths to Python functions or classes -- just
> like INSTALLED_APPS does with module paths. The AppCache should also
> be able to take paths to app classes and create instances of them on
> the fly while startup.
It's a debatable point, and I'm happy to see discussion and comments
from others. I tend to the pragmatic, so how (in more detail) would
you propose tackling the specific use case I mentioned with clashing
auth and comments apps? How would settings.py look in your ideal
scenario?
An analogy with using app instances in settings.INSTALLED_APPS might
arise from looking at how the use of either functions or paths to
functions in allowed in urlconfs. I don't think anyone is insisting
that urlconfs should contain only paths to functions - the utility of
using functions there is well-established, I would say.
> A strong paradigm in Django for extensible features is to inherit from
> base classes and/or implement a simple API and then adding it to the
> settings. I don't see why this shouldn't also be done for apps.
>
I don't see how my suggestion precludes that. I even gave an example
with a derived app class.
>
> Not true if each app instance knows it's full module path. The
> AppCache should use that full python path when handling the list of
> installed apps.
>
The point is, I don't want to touch a third-party app's code if I
don't need to. What if I want to use an existing app which doesn't
care what its full path is? Can you give some code snippets like I
did, to show how things should work, in your view?
>
>
> > 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'),
> > ...
> > )
>
> Or you could just define this externally in the first place and just
> use the path to that subclass. Having to import every specific app
> first in the settings brings unneeded cruft.
>
But I may want to instantiate the app class or subclass with different
parameters, as in my example. There, I want to integrate two sets of
apps with clashing labels ('auth' and 'comments') into a project, and
I can do this using app instances without touching the code of the
apps themselves (assuming they are not written in a pathological way).
Can you indicate using code snippets, in the specific scenario I
mentioned, what the implementation would look like to achieve the
desired results? This would really help me to understand the benefits
of what you are proposing.
Thanks for your time,
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
-~----------~----~----~----~------~----~------~--~---
