On Sat, Jan 28, 2012 at 21:19, David Roe <r...@math.harvard.edu> wrote:
>> % 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
>
> I think this is a good idea. Some suggestions:
> * As Jeroen has pointed out, we should keep a thin shell script that
> calls off to programs like gp and gap, and runs the pkg install
> subcommand.
> * For backward compatibility, why don't we have a shell script that
> prints out a deprecation warning and then translates all of the
> allowable commands in the old syntax to their new equivalents.
Sounds good to me.
> * I would like to still allow "sage -t" as a way to access the "sage
> test" subcommand, "sage -b" to access the "sage build" subcommand,
> etc.
This is fairly straightforward with the argparse in python 3.2+ (it
supports subcommand aliases), however we would have to backport this
functionality since it isn't in the 2.7 copy of argparse. Although, I
don't really like this, subcommands aren't arguments (shouldn't start
with a dash), rather what happens is "hg commit" becomes "hg co".
> I think the key change should be to become Posix compliant, and
> these are allowable short options. And they combine nicely: "sage
> -bta" would mean rebuild everything and test everything.
These commands are odd. For most programs you only ever use one
subcommand at a time, here we use two, and argparse doesn't deal with
this case. What I was thinking of doing was having a subcommand
"buildtest" (with alias "bt") which would pass its arguments to
"build" and then to "test". ("sage -bta" would become "sage bt -a")
> * I think that each of the subcommands should be separated out into
> its own python script that handles the appropriate options.
To clarify, separate modules, or separate scripts? If they are
seperate scripts, then we don't need to rely on argparse's subparser
functionality: we have a thin script that determines the parser to
use, and then run the corresponding parser.
>
> David
>
> --
> 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
