new syntax for management commands

[dffdgsdfgsdfhjhtre]

https://github.com/zacharyvoase/django-boss

http://blog.zacharyvoase.com/2009/12/09/django-boss/

What is the outlook of something like this replacing the current way management commands are handled by django? I'm no the author of django-boss, but I think this syntax is much better and more pythonic than the Java-esque way they are defined now.

[Russell Keith-Magee]

I'll agree that it looks appealing. However, as always, my question is
about backwards compatibility.

As much as I may like the proposed syntax, we can't leave all the
existing command definitions out there high and dry. I haven't done
any investigation of this, and Zach's blog doesn't seem to address the
issue -- at least, not directly; there's a reference to just needing
to import command, but it doesn't make any comment about supporting
the old way. What's the overhead on supporting both the old syntax and
the new syntax in parallel?

Yours,
Russ Magee %-)

[Florian Apolloner]

Hi,

On Sunday, August 12, 2012 2:22:58 AM UTC+2, Russell Keith-Magee wrote:

I'll agree that it looks appealing. However, as always, my question is
about backwards compatibility.

Seriously? In my eyes it's ugly, especially if you have more than one options. Eg imagine you have decorated a function with @argument 6 times. Even though make_option isn't much better in that way I think that a class looks nicer and is easier to skim over.

Maybe usage of argparse might improve a few things to write complex management commands (eg subparsers, http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser.add_subparsers) -- although it's 2.7+

Cheers,
Florian

[Mikhail Korobov]

Some people prefer argparse, some people prefer decorator-based syntax (like django-boss or argh), there are people prefer other methods (e.g. docopt). I think it is better not to invent yet another command-line framework. 

Maybe delegate option parsing to user favorive library and provide some basic utilities for management command registration and execution instead? I didn't think of API yet, but the idea is:

- django code setups settings, validates models, activates proper translation, maybe manages transactions.

- developer registers management command (so it works in e.g. ./manage.py help and call_command); implements some interface (e.g. 'run_from_argv' and 'help' methods); parse options in 'run_from_argv' and do whatever needed.

воскресенье, 12 августа 2012 г., 16:32:49 UTC+6 пользователь Florian Apolloner написал:

[Russell Keith-Magee]

On Sun, Aug 12, 2012 at 6:32 PM, Florian Apolloner
<f.apo...@gmail.com> wrote:
> Hi,
>
>
> On Sunday, August 12, 2012 2:22:58 AM UTC+2, Russell Keith-Magee wrote:
>>
>> I'll agree that it looks appealing. However, as always, my question is
>> about backwards compatibility.
>
>
> Seriously? In my eyes it's ugly, especially if you have more than one
> options. Eg imagine you have decorated a function with @argument 6 times.
> Even though make_option isn't much better in that way I think that a class
> looks nicer and is easier to skim over.

The part that is appealing to me is the reduction of boilerplate. In
99% of cases, a management command should be able to be defined with a
single function. The simplest possible management command at the
moment is a method in a class in a module in a module. That's a lot of
boilerplate.

The multiple @argument decorators don't particularly offend me
personally, but I also don't think the exact syntax for the argument
decorators is the important part of the proposal -- the important part
is the @command decorator, and the 'single function' nature of the end
product. If Zach's proposed @argument decorator doesn't appeal to you,
I'm certainly open to discussion on other ways that the argument
requirements of a command could be defined.

Yours,
Russ Magee %-)

[Alex Gaynor]

--
You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

In my view, the current largest source of boilerplate with management commands is where they have to be, you have to stick them 3 directories deep.  Writing a command itself is pretty boilerplate free.

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[Florian Apolloner]

Hi,

On Monday, August 13, 2012 1:54:36 AM UTC+2, Alex_Gaynor wrote:

In my view, the current largest source of boilerplate with management commands is where they have to be, you have to stick them 3 directories deep.  Writing a command itself is pretty boilerplate free.

Agreed, a saner loading process would definitively help.

Cheers,
Florian

[Melvyn Sopacua]

On 13-8-2012 1:54, Alex Gaynor wrote:

> In my view, the current largest source of boilerplate with management
> commands is where they have to be, you have to stick them 3 directories
> deep. Writing a command itself is pretty boilerplate free.

Ironically, this is easily fixed with a createcommand <app> <name>
management command.

--
Melvyn Sopacua

[Russell Keith-Magee]

IMHO, If you need a helper command to write code for you, something
has already gone horribly wrong. I'll accept the existence of
startproject because a default wsgi and settings file is inherently
complex, but startapp, for example, should not need to exist.

Yours,
Russ Magee %-)