Just to add a quick update here. Not much has happened on the branch since Djangocon - but we had some valuable discussions. I'm hoping to get some time over the holidays to get this back up to a more current form.
Russ and Karen gave some great feedback, and there is some straightforward but somewhat tedious cleanup - mostly involving backing out the metaclass pattern for app objects. The crux will be a way to introduce this in form that provides some limited, targeted benefits such as the verbose app name, without opening too much of a pandora's box of enabling a range of unintended "features" centered on abuse of the app-cache. As Russ said - this has always had the potential to be a ginormous bike-shed, and if any Django specific interfaces on a application class that go beyond "its just a Python class" are to be introduced, they have to be done so with due consideration. -Preston On Friday, December 7, 2012 8:09:22 PM UTC-8, Russell Keith-Magee wrote: > > It's Preston Holme's app-loading branch - the Github branch Ramiro > referenced earlier in this thread. > > https://github.com/ptone/django/tree/app-loading > > Yours, > Russ Magee %-) > > On Sat, Dec 8, 2012 at 12:02 PM, Pedro J. Aramburu > <para...@tres42.com.ar<javascript:> > > wrote: > >> Which one is the branch? I can't seem to find it. >> >> On Friday, December 7, 2012 10:41:16 PM UTC-3, Russell Keith-Magee wrote: >> >>> >>> On Sat, Dec 8, 2012 at 9:29 AM, Pedro J. Aramburu <para...@tres42.com.ar >>> > wrote: >>> >>>> Ramiro, I've read the ticket but it seems stuck. I just want it to go >>>> forward because I think it's a major UI/UX issue for non-programmers the >>>> lack of "pretty" app names. But I want it to be done right with a proper >>>> app metadata handling. >>> >>> >>> You won't get any argument from me, or anyone else in the core team. >>> This *is* an important issue. The problem is that the issue *isn't* >>> entirely cosmetic. It's very easy to say that we "just" need to attach a >>> configurable name to applications -- but in order to do this, you need to >>> address the more fundamental issue of what an application *is*. In having >>> that discussion, you hit a whole raft of *other* problems that are related >>> to Django's definition of apps. That's why this patch has taken so long to >>> come to fruition. >>> >>> The thing is that there isn't any consensus about the way to go so I'm >>>> terrified of starting with my ideas without anyone accepting them and also >>>> because I don't know if anyone is already working on them (as the tickets >>>> are open) but there seems to be no constant activity on them. That's why I >>>> need some guidance from someone experienced with the process. >>>> >>> >>> There's plenty of consensus about the broad strokes. The disagreement is >>> about the little details. There's no constant activity because it's a big >>> problem; that means we've gone through multiple maintainers over time, and >>> the activity level rises and falls as attention is drawn onto other >>> priorities (such as bug fixing for the 1.5 release). >>> >>> I last looked at Preston's Github branch during the DjangoCon US >>> sprints, and at that time, it was extremely close to being ready for >>> merging -- it mostly just needed eyeballs, testing, and documentation. If >>> you want to help out, I'd suggest grabbing that code, and trying to (a) get >>> it up to date, and (b) testing it with your own projects, and © helping to >>> stub out documentation. >>> >>> I'd very much like to see this patch land as part of the 1.6 cycle -- >>> App name translations aren't a big issue for me personally, but all the >>> other related features -- such as having a reliable startup sequence, a >>> place for application-level configuration, and a place for one-time >>> initialisation -- *are* an issue for me, and fixing these problems are all >>> side effects of adding an application configuration object. >>> >>> Yours, >>> Russ Magee %-) >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/django-developers/-/KqGTJ8TPPgcJ. >> >> To post to this group, send email to >> django-d...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> django-develop...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/cFPu8nmwE1cJ. To post to this group, send email to django-developers@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.
