Sage uses non-standard command-line options (e.g., -notebook rather
than --notebook). I propose that we switch to standard ones. Here are
two reasons:
1. They're standard, and standards are good. People used to Unix-type
systems will expect our options to work this way. I think if we
decide to continue not using the standard format, we should have a
good reason.
2. If we use standard command-line options, we can use an existing
command-line parser, like Python's optparse, instead of having our own
home-grown version (in SAGE_ROOT/local/bin/sage-sage). A standard
Python library package is likely to be more robust than something home-
grown. For example, we can solve trac ticket #21 (and the related
ticket #180) this way. For another example, note that "sage -merge"
works but "sage --merge" doesn't; this sort of thing can be fixed on a
case-by-case basis, but it's harder to even introduce such
inconsistencies with optparse.
My proposal is:
(a) first, we include new command-line options but don't turn them on
by default, instead printing a message like this one when you type
"sage [...]" with a nonempty argument:
Note: Using old-style Sage command-line options.
To try out Sage's experimental GNU/Posix-style command-line
options
(for example, 'sage --notebook' instead of 'sage -notebook'), set
the
environment variable $SAGE_NEW_OPTIONS to something nonempty.
To bypass this message, set the environment variable
$SAGE_SKIP_OPTIONS_MESSAGE to something nonempty.
Running "sage" (with no arguments) would not trigger this message.
(Perhaps we could only turn this on in prerelease (alpha and rc)
versions? Alternatively, a change like this could go with the version
5.0 release.)
(b) after a while, we switch this to
Warning: Using old-style Sage command-line options.
Sage is changing to use conventional GNU/Posix-style command-line
options
(for example, 'sage --notebook instead of 'sage -notebook). This
change will
become the default soon. Meanwhile, to use this new style (and
therefore
to avoid seeing this message), set the environment variable
$SAGE_NEW_OPTIONS to something nonempty.
perhaps with no easy way of disabling this message while using old-
style options.
(c) finally, we turn on the new options, perhaps with an environment
variable $SAGE_OLD_OPTIONS to use the old ones, with the understanding
that any changes in command-line options may not be maintained for the
old version.
I have patches to implement this which I can post at trac ticket #21
if people think it's a good idea. I'd be very surprised if my
implementation of the new options doesn't have bugs, but refereeing
and phase (a) would get people to test it out. As far as I can tell,
all spkg-install files for the standard packages would continue to
function: first, they look good at a glance. Second, I applied the
patches, set $SAGE_NEW_OPTIONS to something non-zero, ran "sage --
sdist", and built the new version without issues. I haven't looked at
any optional or experimental spkgs yet.
Opinions? Perhaps we should start a new newsgroup to discuss this? :)
By the way, while investigating this, I came up with some questions:
- What should "sage blah.spkg" do? It looks like it's supposed to
install the spkg, although this isn't documented anywhere that I can
see. Should we keep this behavior, or just make the user type "sage -i
blah.spkg"?
- "sage -log" seems to be broken: it tries to write to the
nonexistent file SAGE_ROOT/changelog.txt. Should we remove it or fix
it?
- "sage -np" seems to be broken, or at least it doesn't do what I
expect (or indeed anything different from just "sage", as far as I
could see). Should we remove it or fix it?
- what is "sage -darcs" supposed to do? I don't know what "darcs" is,
and I don't see any packages which seem relevant.
- what about "sage -axiom"? What package installs axiom? Fricas?
- does anyone use "sage -crap"? "sage -min"? "sage -inotebook"?
- how about "sage -gthread" and friends?
- how about "sage -valgrind" and friends, or "sage -t FILE -valgrind",
etc.?
For any of these, we have several choices: (1) delete them, (2) keep
them, (3) keep them but don't document them (don't list them when you
type "sage --advanced"), (4) ??
--
John
--
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
To unsubscribe from this group, send email to
sage-devel+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
