On Apr 7, 12:40 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:
>
> Strings will be converted to App()... by What? When?
>
This is already done by the #3591 patch, in
django.db.models.loading.py.
> What happens to existing code that is using "for app in INSTALLED_APS"
> as an idiom?
>
The #3591 patch does this by replacing settings.INSTALLED_APPS with
get_installed_app_paths, which obviously wouldn't work for 3rd party
code out in the wild. ISTM that to keep things backward-compatible,
you need two lists - INSTALLED_APPS and an internal list of App()
instances. You could for instance allow users to specify a mixture of
strings and App instances in settings.INSTALLED_APPS, and once the
loading has happened, this list would contain only strings, whereas an
internal list would contain only App instances and be accessed via a
new function such as get_installed_apps().
> > App('django.contrib.contenttypes'),
> > App('django.contrib.sessions'),
> > App('django.contrib.sites'),
> > App('django.contrib.messages'),
> > App('django.contrib.admin'),
> > App('django.contrib.admin', name=‘demo’),
> > )
>
> > The InstalledApps and App classes will be added to core.apps. The
> > db.models.loading module will be deprecated and redirect to core.apps.
>
> Is there a specific reason for this move? Is it just shuffling
> deckchairs, or is there a purpose behind the move?
>
If apps are to have first-class-citizen status, then this I suppose
would serve to emphasize that status, but other than that I'm not sure
it's necessary.
>
> I agree with Alex - there's a lot more detail needed here. How will I
> get access to the App instance that a model belongs to? How will
> legacy attributes like db_prefix be proxied? What is the order of
> precedence when a model and an app disagree on db_prefix?
>
Agreed that a more detailed specification is required, but wouldn't at
least some of that detailing be part of the actual GSoC work?
> For the record - I don't think the "multiple versions of a single app"
> problem is one worth solving. I'm not even convinced it can be solved
> at all, for all the reasons Florian identified, and then some.
I agree, but IIRC it was quoted as one reason why this feature was
left out of the running in the recent Django revisions. It doesn't
make a lot of sense to me for any app where models are concerned, and
I believe there would be no point in duplicating the models for
multiple instances of an app.
> Although it may have been part of the original use case for #3591,
> much of that use case has since been replaced by namespaced URLs and
> class-based applications. If you're going to tackle this problem, I'd
> rather see you concentrate on issues like:
Class-based applications? Can someone point me to some of those?
Googling for "django class-based applications" doesn't throw up
anything.
> * Translating application names
This is handled in the #3591 patch AFAIK.
> * Solving the "two applications called auth" problem
> * Providing configurability for db-level naming convention at the
> deployment level (e.g., so you can override db_prefix and table names
> when you deploy an app)
> * Providing configurability for 'app level' settings; for example,
> when deploying contrib.comments, setting the name of the model that
> will be used for content.
>
> > Step 3
> > ---------
> > The current app loading implementation in Django was designed to load model
> > classes. However, there are many applications which just provide
> > templatetags or management commands and don’t use Django’s ORM at all. These
> > applications have to ship with an empty models.py file in order to be loaded
> > correctly. The goal of Step 3 is to make it possible to load applications
> > without a models.py file.
>
> I would have thought this step would have been a logical consequence
> of Step 1; if you're going to massively rewrite app loading, it would
> seem unusual to embed all the old problems in your rewrite.
>
I think that would all come out in the wash; for example the #3591
patch doesn't require a models.py, and the app instance has slots for
two modules: the app package itself and the models sub-package or
module within it. It should be very easy to handle the case of an app
with no models.
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
