On Wednesday, March 28, 2012 at 9:16 AM, Nauho Zen wrote:
> > I believe that the baton was somewhat passed to tswicegood at pycon, see:
> >
> > https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba
> >
>
> I will take a good look at it.
The best place to start is the pull request:
https://github.com/django/django/pull/129
That has the current state of the app-loading branch against Django's master
branch.
Before I go into any further specifics, one thing I want to do (whether this
makes it into GSoC or not) is make sure that we keep the scope reigned in on
this merge. From my point-of-view (and hopefully Jannis will correct me if I'm
off) these are the things this branch should do:
* Introduce the concept of an App object to represent each
* Keep the concept of an `app_label` as just the last part of an app's module
name (example: django.contrib.auth has an app_label of auth).
* Be entirely backwards compatible
The majority of the above work is already done. Right now the two biggest
hurdles to getting the code merged in are:
* Getting the main test suite running again. The tests break spectacularly
with the new code. Some of the failures are tests using internal APIs that
changed, other are valid public APIs that haven't been ported yet. Ideally
this merge should be able to take place without a single test having to be
changed.
* Buy-in from all of the core-devs that this is a needed and/or good change.
All of this said, I'd love for this to be a GSoC project, but I agree Preston
that yet-another-GSoC slot spent on this might not be the best use of the
project's GSoC slots.
> > This is, as far as I can tell from my review, and unresolved limitation in
> > the current branch - that django.contrib.auth and mypackage.auth collide.
> > Seems a duplicate of your #3 below.
> OK, there is still not a workaround way?
There is not a way to work around this. The app-loading branch provides a path
forward, but does not take it. I don't think this pull request should fix this
problem.
Dealing with application conflicts requires a broader design decision on what
constitutes an application's "name": it's app_label
("django.contrib.auth".split(".")[-1]), or it's full name
("django.contrib.auth"). The biggest issue is backwards compatibility -- we
have to keep app_label around for awhile, so we need to deal with both. We
can't immediately switch all table names around to refer to something other
than the app_label.
> > > 2) can deploy several instaces of the same application
> >
> > If you see the discussion here:
> >
> > http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea
> >
> >
> > It was determined that this feature was too problematic to tackle as part
> > of app_loading
> A good start point to check if previous work has solved this problem or not ?
This is a problem and I recommend punting on it (see above).
-T
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
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.
