On Sun, Jan 29, 2012 at 13:55, R. Andrew Ohana <andrew.oh...@gmail.com> wrote:
> On Sat, Jan 28, 2012 at 21:19, David Roe <r...@math.harvard.edu> wrote:
>> * 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".
`hg co` actually is aliased to `hg update`, NOT `hg commit`, because
it's a common abbreviation for "checkout" (which is I guess
Mercurial's effort to be friendly to SVN users). But in any case, this
is different from short/long options as in the getopt/posix syntax. hg
just accepts any unambiguous abbreviations: `hg up` expands to `hg
update`, but so does `hg upd` or `hg upda` etc.
>> 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.
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 .
-Keshav
----
Join us in #sagemath on irc.freenode.net !
--
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
