On Fri, Jan 27, 2012 at 2:04 AM, 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)+1, I like the subcommands direction. I think sage foo ... should default to running bin/sage-foo (in the sage environment) if it exists, and treat foo as a file otherwise. Virtually no argument parsing (aside from understanding --) would be involved here, and the decision to use bash/python/... would be delegated to the subscripts. "sage sh ..." would be sufficient for the "-C" option suggested, but "sage gap" and "sage gp" etc. would be natural to have directly. "sage run" could be provided to treat its argument(s) as files too. I would like it to be easy to do "sage -br" and "sage -bt" One option would be to expand these into "sage run --build" and "sage test --build" which would invoke the "build" script first. Another option is to add "global flags" like hg has (see hg -v help) one of them being "build first," but if we go this route I'd like to keep these to a minimum (and "sage -b test" looks a bit odd to me). > 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). There are deprecation issues to worry about, but we could keep "sage [options]" and "sage non-subcommand-file" as they are for the moment. - Robert -- 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
