What do you think is required to get it into the trunk? I don't think the objections on #11745 are valid -- 1) If an app overrides builtin command, it would be quite confusing to see that command still under built-in app, as that would give you no hint that the command was overwritten. 2) I'm not quite sure how ./manage.py help --list would help -- if someone is parsing the list, they'll have to change their script anyway.
On Jul 10, 9:13 pm, Russell Keith-Magee <[email protected]> wrote: > On Sunday, July 10, 2011, George Karpenkov <[email protected]> wrote: > > Hi everyone, > > Recently I'm becoming more and more annoyed with ./manage.py help behavior > > -- in projects with many dependencies it's virtually impossible to find the > > command you need as there are just too many, and searching for the one you > > need takes ages (and ages and ages). > > So I thought that grouping by app can make the output much better, and > > implemented grouping-by-apps in the help command. > > One detail I'm not too sure about is that in get_command() for some(?) > > reason 'startapp' command maps to ProjectCommand, while every other command > > maps to the corresponding app. I've hardcoded the special-case-check for > > ProjectCommand, but it would be nice to know why it was done this way in > > the first place. > > Corresponding ticket with patch -https://code.djangoproject.com/ticket/16445 > > As I have noted on the ticket; this has been proposed in the past - see > #11745. > > Yours, > Russ Magee %-) -- 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.
