On Jan 29, 2012, at 7:57 PM, Keshav Kini wrote:
>>> 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 find this really ugly to be honest. Subcommands are supposed to be
> for launching entirely difficult functionalities from each other, no?
> Making one subcommand that basically runs two other ones in order
> seems bizarre. This is starting to make me question whether
> subcommands are really a good idea. Maybe we should just have long and
> short options a la getopt/posix, with some well defined execution
> order, for example first do a build if -b or --build is specified,
> then do a test if -t or --test is specified, then run, either the
> notebook if -n or --notebook is specified, or the bare console, if -r
> or --run is specified or if none of -b, -t, -n, or -r or their long
> versions were specified. All external programs could be handled by the
> thin shell script.
I agree it's ugly. I think what the user really wants is things like
sage test --build-first
rather than
sage build test
I can't imagine any ever wanting
sage build shell test notebook
In other words, the test command would know how to (optionally) build first,
but the build command wouldn't know how to test afterwards. I suppose run
could know how to build and test first, but I don't see a real use case for
that off the top of my head.
> Or actually, why don't we just create an option "-C/--shell-command"
> which feeds "-c" to the sage subshell? Then we would have, for
> example, "sage -C gp" or "sage -C python" or whatever, which just adds
> two characters. Some of the commands which call external programs seem
> to have some initialization stuff done before the program is actually
> called, so we could prepend some directory to PATH in sage-env which
> contains scripts named after the actual program binaries in
> $SAGE_LOCAL/bin, that initialize and call the actual program binaries,
> just as we are currently doing with a bunch of five-line if statements
> in $SAGE_ROOT/spkg/bin/sage .
This would be a nice feature to have, but I want to be able to run something
like
sage gap -o 2g
to tell GAP how much memory to use. I _think_ sub command parsers handle that
where as I would have to run
sage -C gap -- -o 2g
if there were no subcommands.
-Ivan
--
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
