The code you removed was trying to catch an error created by using
illegal options or arguments in one of the commands. Apparently optparse
still prints the usage message, but you also see the Python error.
It looks like sys.exit(3) is raising an exception that no one has ever
noticed before. Not
On 9/9/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> It would seem this broke reloading of the built-in web server.
I've fixed that in [6094].
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you
On Sun, 2007-09-09 at 23:25 -0500, Adrian Holovaty wrote:
> On 9/9/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I see the problem. The reloader uses sys.argv and grabs the last command
> > line directly. By the time it gets to runserver.Command.handle, the
> > command line has been munged a lit
On 9/9/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> So if we have several confirmations of breakage, shouldn't it be
> rolled back?
Nah, no need to roll this one back, unless it takes forever to figure
out. The changeset has too many files, and the breakage isn't
horrible.
Adrian
--
Adrian Hol
On 9/9/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I see the problem. The reloader uses sys.argv and grabs the last command
> line directly. By the time it gets to runserver.Command.handle, the
> command line has been munged a little.
That doesn't make any sense, though. Which part of the code
On Sep 10, 2:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Hmm, I confirm I get the same error on OS X -- it happens after the
> server is reloaded. How strange...
So if we have several confirmations of breakage, shouldn't it be
rolled back?
--~--~-~--~~~---~
On Sun, 2007-09-09 at 21:55 -0500, Adrian Holovaty wrote:
> On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > I'm seeing breakage too: I haven't tested it that extensively, but I'm
> > getting the following pair of tracebacks consistently on Windows on
> > the first reload of the serve
On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm seeing breakage too: I haven't tested it that extensively, but I'm
> getting the following pair of tracebacks consistently on Windows on
> the first reload of the server:
Hmm, I confirm I get the same error on OS X -- it happens afte
On 9/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-09-09 at 23:41 +, SmileyChris wrote:
> > On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > > On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > >
> > > > I think my refactoring of django.core.managemen
On Sun, 2007-09-09 at 23:41 +, SmileyChris wrote:
> On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > > I think my refactoring of django.core.management to let each command
> > > register its own options is complete
On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've committed it in [6075].
It would
On Sun, 2007-09-09 at 17:16 -0500, Adrian Holovaty wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've committed it in [6075]. I left a few commen
On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I think my refactoring of django.core.management to let each command
> register its own options is complete.
Great stuff, Todd. I've committed it in [6075]. I left a few comments
at http://code.djangoproject.com/ticket/5369 about the main chang
I think my refactoring of django.core.management to let each command
register its own options is complete. (Can anybody think of a good way
to test everything, other than running stuff by hand, which I've been
doing?)
I did hit a couple of issues:
1. The args for loaddata had 'fixture, fixture,
On 9/2/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Any objections to requiring the second form?
I don't have any huge objections, and it makes sense that we'd require
this, given that each command knows what its valid options are.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
-
On 9/2/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> How would people feel about going to an svn style for help? My specific
> proposal is that 'help' would be added as a possible command.
>
> $ django-admin.py help
>
> would list all possible commands.
>
> $ django-admin.py help command_name
>
>
On 9/3/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> How would people feel about going to an svn style for help? My specific
> proposal is that 'help' would be added as a possible command.
+1. When there were only a few commands, a single help page made
sense, but now that there are dozens of c
Currently,
$ django-admin.py --help
returns a usage guide for every command available. It's long and lists
all command options at the bottom, even though some are only appropriate
for some commands. Because of this, each command has to list which
options it allows separately and these appear in
Currently, both of the following work:
$ django-admin.py --opt value command_name [1]
$ django-admin.py command_name --opt value [2]
because django-admin.py is the actual command and the command_name is
just an arg.
If we create a parser that only admits options that are valid for the
given co
On Tue, 2007-08-28 at 10:55 -0500, Adrian Holovaty wrote:
> On 8/28/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Here's a suggestion to pull the options out of
> > django.core.management.ManagementUtility: What if we just read the
> > command after manage.py/django-admin.py and then passed the
20 matches
Mail list logo
