On Fri, Jan 27, 2012 at 02:26, David Roe <r...@math.harvard.edu> wrote:
> We're working on rewriting the doctest framework only. So we're still
> just sticking to hyphens, but are making them UNIX-compliant: --gdb
> instead of -gdb for example. My first impression of your proposal is
> that I like it, though there are some ambiguities in the syntax: in
> mercurial the subcommand is required, whereas in sage we would also
> want to allow "sage ARGS". So you have to be careful what you mean by
> "sage test": are you running sage on a file called test, or are you
> running the subcommand test with no arguments.
This was actually brought up in the python ticket to add optional
subparsers to argparse [1], however it is not completely unheard of, I
know at least aptitude does this.
Maybe I should have put "sage OPTIONS", since I envision that all
commands that don't use a subparser to not need any arguments (like
--help, --root, etc.), so there would be no ambiguity since those
would only start with dashes. The only exeption to this rule would be
sage scripts, which would occur if you wanted to run a script simply
title say 'test' or 'build' or 'python', but you shouldn't be doing
that anyway since the script should have a suffix.
>
> I think that we can separate out the functionality which should be
> available before building python (sage -i for example). Overall I
> think using python for the majority of sage's option parsing is a good
> idea.
> David
>
> On Fri, Jan 27, 2012 at 02:20, R. Andrew Ohana <andrew.oh...@gmail.com> wrote:
>> On Fri, Jan 27, 2012 at 02:07, David Roe <r...@math.harvard.edu> wrote:
>>> Come over to Padelford: Robert and I are working on something like this.
>>> :-)
>>
>> Is it at all similar to what I proposed? If not, please share :)
>>
>>> David
>>>
>>> On Fri, Jan 27, 2012 at 02:04, 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
>>>
>>> --
>>> 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
>>
>>
>>
>> --
>> 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
>
> --
> 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
--
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
