On Dec 5, 2007 2:48 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Great to hear this is gaining some momentum. I'm not a fan of the
> patch on 3591, as it goes only halfway (by adding the app() function),
> stopping short of a full, elegant solution. The approach I've been
> wanting to take is to make INSTALLED_APPS an instance of an
> AppCollection class (insert better name here), which is a collection
> of App instances, each of which has a configurable label (and other
> configuration). With that in place, any code that needs to iterate
> over the INSTALLED_APPS will simply do something like this:
>
>     from django.conf import settings
>     for app in settings.INSTALLED_APPS:
>         print app.label
>         print app.verbose_name # Finally apps can have a human-readable name!
>         # print whatever else...

Not that it would matter for most people, but would that mean you
could install the same app twice, under different names? For instance,
when building an online game, you might have a Places app to keep
track of places in an in-game world, but you'd also like to use it to
store actual player locations (in the real world). You clearly
wouldn't want these two to mix, so it might be useful to have
something like this:

INSTALLED_APPS = AppCollection(
    App('basic.places', label='game_places'),
    App('basic.places', label='real_places'),
)

Then, the models in the Places app would be installed twice, once for
each label, using the label as a prefix. That's probably too much of
an edge case to go out of our way for, but if it just happened to be
supported, it could make for something interesting things. Yes, I know
it's a pony.

> Maybe *args would be interpreted as App classes and **kwargs could be
> for AppCollection-level options, like this:
>
>     INSTALLED_APPS = AppCollection(
>         some_option=True,
>         App('django.contrib.admin'),
>     )

Surely you meant to have the positional arguments come before the
keyword arguments. ;) I wonder if it would also be useful to allow
additional AppCollection instances in addition to App instances. I
keep thinking about Satchmo, which has several apps, most of which are
necessary for a fully-functional store. If they could provide an
importable AppCollection instance, it'd be nice if we could include
that alongside the rest of our apps.

from satchmo import apps

INSTALLED_APPS = AppCollection(
    App('django.contrib.admin'),
    apps.full_store,
)

But that's probably too much of an off-shoot request, especially since
it would introduce another import into settings.py

> I'm not sure what options would be available to an AppCollection, but
> at least this gives us the flexibility for options in the future.

Even not supporting **kwargs at all right now still gives us the
flexibility for options in the future. We can just add ", **kwargs" to
AppCollection.__init__ and away we go. It wouldn't cause any breakage
to add that later on. But I like the idea, even though I can't think
of any real use for it yet, either.

-Gul

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to