> 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.
>
I will import this important part to my proposal, which will help a lot if I am
accepted to finish off the "App Refactor" work.
> 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.
>
Well, as a candidate student, I still cann't judge the whole workload
should be paid
in this project and don't know whether if it make the best use of GSoC
slots. However, if because it has been taken as a project in previous
GSOC which make
a similar idea (finish off old work) not that significant to be a 2012
project, then
how about taking it as one part of 2012 work which I may charge if
accepted, and at the same time importing more interesting ideas that
can help my proposal make the best use of our slots?
Travis and Preston, what's your opinion?
> 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.
OK. I will consider that.
> 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.
OK.
> This is a problem and I recommend punting on it (see above).
OK.
Best regards,
nauho
--
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.
