sage-sage script
Joel B. Mohler
usage from the very beginning. I would like to rewrite it using python's
optparse module and make it gnu long option correct. This means some
changes:
1) All long options start with a double-dash. -upgrade, -gdb and friends
will need to be --upgrade,--gdb
2) The basic/advanced dichotomy isn't built into optparse as far as I know.
I'd be inclined to scrap the splitting altogether, but I'd be willing to hack
the automatic help support for optparse and coax it into doing something
similar.
There are some good things though. The special combined options
like -ba, -br, -ba-force come for free. Optparse will interpret "-br"
as "-b" and "-r" and I'll just have to actually execute the appropriate
things in order.
Any comments, delight, screaming?
--
Joel
Carl Witty
idea! Thank you!
Then the comments:
Switching to double-dash will be painful; my fingers know the old
option spellings. But I'm willing to live with the pain to have a
saner version of sage-sage.
I think it's very nice that "sage -h" gives a single-page summary of
the most important options. However, if that's difficult to do using
the automatic help support in optparse, I think it would be fine to
have this single-page summary be hand-written, and use the automatic
support only for "sage --advanced" (which would then list all the
"sage -h" options again).
As a developer, I have occasionally found it handy that sage-sage
keeps working even if I manage to screw up Sage's Python
installation. I suggest that the option parsing for "sage -i", "sage -
f", and "sage -sh" move to $SAGE_ROOT/sage (and stay in shell script);
in my opinion, these are the three most important options for
debugging/repairing the sorts of low-level problems with a Sage
installation that might keep Python from working.
Carl
William Stein
>
> On Mar 1, 6:05 am, "Joel B. Mohler" <j...@kiwistrawberry.us> wrote:
> > This script and it's option handling has made me cringe and annoyed me with
> > usage from the very beginning. I would like to rewrite it using python's
> > optparse module and make it gnu long option correct. This means some
> > changes:
> >
> > 1) All long options start with a double-dash. -upgrade, -gdb and friends
> > will need to be --upgrade,--gdb
> >
> > 2) The basic/advanced dichotomy isn't built into optparse as far as I know.
> > I'd be inclined to scrap the splitting altogether, but I'd be willing to hack
> > the automatic help support for optparse and coax it into doing something
> > similar.
> >
> > There are some good things though. The special combined options
> > like -ba, -br, -ba-force come for free. Optparse will interpret "-br"
> > as "-b" and "-r" and I'll just have to actually execute the appropriate
> > things in order.
> >
> > Any comments, delight, screaming?
>
> I have both comments and delight. First the delight: Yay! Great
> idea! Thank you!
>
> Then the comments:
>
> Switching to double-dash will be painful; my fingers know the old
> option spellings. But I'm willing to live with the pain to have a
> saner version of sage-sage.
I'm not. Can't we just make both - and -- work?
> I think it's very nice that "sage -h" gives a single-page summary of
> the most important options. However, if that's difficult to do using
> the automatic help support in optparse, I think it would be fine to
> have this single-page summary be hand-written, and use the automatic
> support only for "sage --advanced" (which would then list all the
> "sage -h" options again).
Yes, the separation of help into simple and advanced is
very nice. I did it because people were being confused
to no end by having all the options listed at once.
> As a developer, I have occasionally found it handy that sage-sage
> keeps working even if I manage to screw up Sage's Python
> installation.
As the person who wrote sage-sage, the reason I wrote it
in shell script was because I very much did not want to
assume that Python was available -- in fact during the install
process, I'm pretty sure I made assumptions that sage-sage
would work even if Python isn't available. Two points:
(1) When I wrote sage-sage it was at first about 100 lines
of code; now it is a space monster, and a rewrite is very
much in order.
(2) Depending on Python might not be an issue anymore;
I don't know. This is only an issue at build time, so it could
be programmed around. Hey, Carl mentions exactly this point
below.
> I suggest that the option parsing for "sage -i", "sage -
> f", and "sage -sh" move to $SAGE_ROOT/sage (and stay in shell script);
> in my opinion, these are the three most important options for
> debugging/repairing the sorts of low-level problems with a Sage
> installation that might keep Python from working.
Hey Nick A., I hope you comment on Joel's proposal.
You bravely rewrote sage-sage once. But the rewrite
didn't work on some os's for me, and I *couldn't understand it (!)*,
since it was such elaborate shell script, which is why it
didn't go in.
-- William
Joel B. Mohler
> This script and it's option handling has made me cringe and annoyed me with
> usage from the very beginning. I would like to rewrite it using python's
> optparse module and make it gnu long option correct. This means some
> changes:
Let me suggest a possibly more manageable first step. We could shorten the
list of options considerably by eliminating the '-maxima,-gap,-program,-etc'
type of options and use the '-sh' like this:
sage -maxima == sage -sh maxima
This would make this shell script a bit shorter and maybe be a good first stab
and rewriting it.
Note that what I suggested doesn't quite work since 'sage -sh' explicitly runs
$SHELL which means that maxima would get interpretted as a bash script (on my
system) ... not good. An alternative is to replace the $SHELL with "sh -c"
when given a program to run. Otherwise run $SHELL.
Note that if you are opposed to the extra typing of 'sage -sh maxima', you
probably actually already run the sage maxima by using the maxima shell
script which is suggested in some sage manual somewhere.
--
Joel
Joel B. Mohler
> > Switching to double-dash will be painful; my fingers know the old
> > option spellings. But I'm willing to live with the pain to have a
> > saner version of sage-sage.
>
> I'm not. Can't we just make both - and -- work?
We probably can't make both work while using a standard (non-hacked) parser.
Naturally, I think it's much more to the point to get used to '--' since it's
very standard anyhow.
The concern about not relying on the sage python is a pretty big problem. On
a similar vein, this probably is precisely why this can't be a shell script
either. Rewriting this in a modern way with bash (for instance) is going to
be a huge problem since older bash/sh are not nearly so featureful.
--
Joel
William Stein
>
> On Saturday 01 March 2008 09:05:04 am Joel B. Mohler wrote:
> > This script and it's option handling has made me cringe and annoyed me with
> > usage from the very beginning. I would like to rewrite it using python's
> > optparse module and make it gnu long option correct. This means some
> > changes:
>
> Let me suggest a possibly more manageable first step. We could shorten the
> list of options considerably by eliminating the '-maxima,-gap,-program,-etc'
> type of options and use the '-sh' like this:
> sage -maxima == sage -sh maxima
> This would make this shell script a bit shorter and maybe be a good first stab
> and rewriting it.
>
No.
> Note that what I suggested doesn't quite work since 'sage -sh' explicitly runs
> $SHELL which means that maxima would get interpretted as a bash script (on my
> system) ... not good. An alternative is to replace the $SHELL with "sh -c"
> when given a program to run. Otherwise run $SHELL.
>
> Note that if you are opposed to the extra typing of 'sage -sh maxima', you
> probably actually already run the sage maxima by using the maxima shell
> script which is suggested in some sage manual somewhere.
Your only argument for this is to make it easier for you to implement
sage-sage. That's not a good enough argument.
> We probably can't make both work while using a standard
> (non-hacked) parser.
> Naturally, I think it's much more to the point to get used to '--' since it's
> very standard anyhow.
I like having the single dash option as well, since I then don't
have to type as much.
Michael: "maybe use has_opt from local/bin/sage-doctest... oh,
and GNU is not the law."
But by the way the "sage-sage" runs without Python necessarily being
built is a potentially _very_ serious issue.
-- William
Carl Witty
> But by the way the "sage-sage" runs without Python necessarily being
> built is a potentially _very_ serious issue.
built. To build, $SAGE_ROOT/makefile calls spkg/install, which runs
the makefile spkg/standard/deps, which does the installations using
sage-spkg directly.
Carl
Joel B. Mohler
Well, I thought it was all about deleting about 50 lines of code from that
file -- some of which has very annoying bugs. Try and use the a command
like:
sage -hg -m "a commit comment"
It busts grandly because of broken $@, $$ bash-isms. I tried to fix that one
day and I concluded that the layers of bash scripts involved was far more
than I ever wanted to know about. I think this would remove one (or more)
layers. My suggestion seems to me to produce far more manageable code.
> > We probably can't make both work while using a standard
> > (non-hacked) parser.
> > Naturally, I think it's much more to the point to get used to '--' since
> > it's very standard anyhow.
>
> I like having the single dash option as well, since I then don't
> have to type as much.
>
> Michael: "maybe use has_opt from local/bin/sage-doctest... oh,
> and GNU is not the law."
>
> But by the way the "sage-sage" runs without Python necessarily being
> built is a potentially _very_ serious issue.
If Micheal is suggesting has_opt as an alternative to optparse, I'm not sure
what the point is. Firstly, it appears as though using python is highly
suspect. But, more-so, if we aren't going to actually use standard option
parsing, it probably won't be as flexible as I think it could (and should)
be.
No, GNU ain't the law, but I'd much rather have GNU option parsing than any
other alternative I've ever seen. Nevertheless, it appears clear that my
love of GNU option parsing is not shared. That's fine, if that's the final
decision though, I have no joy in writing ad-hoc option dealing code so I'll
decline...
--
Joel
Nick Alexander
be flexible in bash/sh is not worth the effort. I also hate the
single dashes, I find them irritatingly non-standard.
With regards to single and double dashes: if I understand correctly,
one can provide short and long options. For example, 'b' and
'build'. One optionally uses single dashes for short and double
dashes for long. So 'sage -b' still works, but to be verbose one
must use 'sage --build'. The things that would change are 'sage -
coverage' etc.
I worry that the overhead of processing with python will slow some
things down, namely 'sage -hg'. It's sucks to wait even half a
second for that frequently used command... and it's running every
time I save a file in emacs. Any lag is noticeable.
Nick
> Well, I thought it was all about deleting about 50 lines of code
> from that
> file -- some of which has very annoying bugs. Try and use the a
> command
> like:
> sage -hg -m "a commit comment"
> It busts grandly because of broken $@, $$ bash-isms. I tried to
> fix that one
> day and I concluded that the layers of bash scripts involved was
> far more
> than I ever wanted to know about. I think this would remove one
> (or more)
> layers. My suggestion seems to me to produce far more manageable
> code.
PS. This works now. I had to report the bug at least 4 times over a
period of a year, but it is now working :) The error was actually in
sage/sage, not sage/local/bin/sage-sage.
Joel B. Mohler
> I am firmly with Joel Mohler. Trying to do this all this parsing and
> be flexible in bash/sh is not worth the effort. I also hate the
> single dashes, I find them irritatingly non-standard.
>
> With regards to single and double dashes: if I understand correctly,
> one can provide short and long options. For example, 'b' and
> 'build'. One optionally uses single dashes for short and double
> dashes for long. So 'sage -b' still works, but to be verbose one
> must use 'sage --build'. The things that would change are 'sage -
> coverage' etc.
Oh yes, absolutely, we should maintain short option synonyms for common things
(but a short option must be a short option -- one letter per gnu standard).
I guess we might have to argue about what is "common". I think we should
have '--long-option' for absolutely everything. Then, we can
have -b, -r, -a, synonyms and they combine effortlessly to form 'sage -bar'.
> I worry that the overhead of processing with python will slow some
> things down, namely 'sage -hg'. It's sucks to wait even half a
> second for that frequently used command... and it's running every
> time I save a file in emacs. Any lag is noticeable.
I wouldn't anticipate that being a problem. I was pleasantly shocked when I
ran 'sage -coverage' and discovered it was virtually instantaneous (and
sage-coverage is a python script).
> > Well, I thought it was all about deleting about 50 lines of code
> > from that
> > file -- some of which has very annoying bugs. Try and use the a
> > command
> > like:
> > sage -hg -m "a commit comment"
> > It busts grandly because of broken $@, $$ bash-isms. I tried to
> > fix that one
> > day and I concluded that the layers of bash scripts involved was
> > far more
> > than I ever wanted to know about. I think this would remove one
> > (or more)
> > layers. My suggestion seems to me to produce far more manageable
> > code.
>
> PS. This works now. I had to report the bug at least 4 times over a
> period of a year, but it is now working :) The error was actually in
> sage/sage, not sage/local/bin/sage-sage.
Ah, that's good to know. I had "fixed" one place (I forget where), but it
wasn't really fixed. I then simply installed mercurial via my distribution
and promptly forgot sage's version.
--
Joel
Robert Bradshaw
to be more standard (and comprehensible) in its argument parsing.
On Mar 1, 2008, at 11:51 AM, Joel B. Mohler wrote:
> On Saturday 01 March 2008 02:30:34 pm Nick Alexander wrote:
>> I am firmly with Joel Mohler. Trying to do this all this parsing and
>> be flexible in bash/sh is not worth the effort. I also hate the
>> single dashes, I find them irritatingly non-standard.
>>
>> With regards to single and double dashes: if I understand correctly,
>> one can provide short and long options. For example, 'b' and
>> 'build'. One optionally uses single dashes for short and double
>> dashes for long. So 'sage -b' still works, but to be verbose one
>> must use 'sage --build'. The things that would change are 'sage -
>> coverage' etc.
>
> Oh yes, absolutely, we should maintain short option synonyms for
> common things
> (but a short option must be a short option -- one letter per gnu
> standard).
> I guess we might have to argue about what is "common". I think we
> should
> have '--long-option' for absolutely everything. Then, we can
> have -b, -r, -a, synonyms and they combine effortlessly to form
> 'sage -bar'.
The problem with allowing both long and short one-dash options is
stuff like "sage -coverage" would equal "sage -c -o -e -r -a -g -
e" (assuming that these were all valid options). I do like the single
dash for simple options (whether this is out of habit or lazyness, I
don't know. They're usually with things that I wouldn't combine with
others, e.g. -coverage, -upgrade, -sh, -notebook and having to put
two dashes there seems strange).
Perhaps a short whitelist of single-dash functions (e.g. the "non-
advanced" commands) that would get parsed to double-dash?
- Robert