On Friday, January 27, 2012, William Stein <wst...@gmail.com> wrote:
> I'm +1 to making sweeping changes to argument syntax & parsing in
sage-5.0 or sage-6.0.
>
Though I don't want to loose any features... and have some respect for our
1-year deprecation policy.
> On Friday, January 27, 2012, R. Andrew Ohana <andrew.oh...@gmail.com>
wrote:
>> So I've been looking into restarting ticket #21 now that we have
>> argparse in python 2.7. The basic premise of the ticket was to make
>> our command line options use a standard library, however, since it was
>> opened (a long time ago), the command line options have become an
>> incredibly cluttered mess as more and more functionality has been
>> added. To that end, I think we should discuss some sort of uniform
>> design to command line options. Looking through what sorts of
>> arguments we already have, and playing around with argparse, I
>> personally came to the conclusion that sage would do well with
>> subcommand/subparsers (like mecurial, git, apt-get, aptitude, ...).
>> Some examples:
>>
>> % sage ARGS # this would be for running sage scripts, or a couple of
>> oddball arguments
>> % sage notebook ARGS
>> % sage pkg ARGS # this would include spkg stuff
>> % sage pkg install # since install has some special flags like -f or -s
>> % sage test ARGS
>> % sage build ARGS
>> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
>> as subcommands of sage
>>
>> Obviously, this is a fairly significant departure from the current set
>> command line options, and I'm not convinced this is necessarily the
>> best way to handle them (I don't necessarily see how to add in
>> debugging options), which is why I'm bringing this up as more of a
>> brainstorm rather than any sort of vote (that may be a future thread,
>> depending on the fallout of this one).
>>
>> So as far as feedback I would like
>>
>> 1) If you think the above is the general direction we should go, any
>> thoughts on how it could be improved, and why (also, a +1 wouldn't
>> hurt, if you don't have any suggestions)
>> 2) If you don't like the direction of above, but have some other idea
>> of how we could go about it, and why
>> 3) You don't think we should make any effort to clean up command line
>> options, and why
>>
>> For 3, I'm well aware that current users would need to relearn command
>> line options (which is the main argument I see for that perspective),
>> but ideally any new set of commands should be intuitive, and easy to
>> learn (plus we have the deprecation period for a reason). If you think
>> this is a more serious issue than I am making it out to be, please let
>> me know (and "I don't want to relearn the command line" does not make
>> a serious issue).
>>
>> --
>> Andrew
>>
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
>> For more options, visit this group at
http://groups.google.com/group/sage-devel
>> URL: http://www.sagemath.org
>>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
>
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
