Differences between revisions 2 and 3
Revision 2 as of 2010-06-01 21:58:03
Size: 2589
Editor: RalfHemmecke
Comment:
Revision 3 as of 2014-07-20 20:25:13
Size: 2575
Editor: chapoton
Comment: no more mercurial
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
In addition to that, Sage might change its command line interface in such a way that it looks more like that of modern source code management systems (e.g., Mercurial). In addition to that, Sage might change its command line interface in such a way that it looks more like that of modern source code management systems (e.g., Git).
Line 15: Line 15:
sage hg sage git
Line 17: Line 17:
would start Mercurial. Any additional arguments would be passed to hg. would start Git. Any additional arguments would be passed to git.
Line 25: Line 25:
Similar to {{{hg}}}, {{{sage help}}} would list of all available commands. Furthermore {{{sage help COMMAND}}} would return an appropriate help for all the options that correspond to {{{COMMAND}}}. Such a system would be pluggable, since it does not need to hardcode all help text in a central place. Rather the help text for a command should be produced by the respective script. (Currently there is already an infrastructure of the {{{sage-*}}} scripts. Similar to {{{git}}}, {{{sage help}}} would list of all available commands. Furthermore {{{sage help COMMAND}}} would return an appropriate help for all the options that correspond to {{{COMMAND}}}. Such a system would be pluggable, since it does not need to hardcode all help text in a central place. Rather the help text for a command should be produced by the respective script. (Currently there is already an infrastructure of the {{{sage-*}}} scripts.
Line 55: Line 55:
  hg:: should be identical to calling Mercurial directly.   git:: should be identical to calling git directly.

SEP: Unifying Sage's command line interface

This SEP proposes to come up with a new command line interface that is more in line with getopt.

Proposal

Sage should use the standard getopt way for its options. http://www.systhread.net/texts/200704optparse.php In particular long options must start with two dashes instead of the current practice just one or two. This is in line with http://trac.sagemath.org/sage_trac/ticket/21.

In addition to that, Sage might change its command line interface in such a way that it looks more like that of modern source code management systems (e.g., Git). For example,

sage git

would start Git. Any additional arguments would be passed to git. Other example.

sage gap

would start gap. As an exception sage would start the Sage session itself.

Similar to git, sage help would list of all available commands. Furthermore sage help COMMAND would return an appropriate help for all the options that correspond to COMMAND. Such a system would be pluggable, since it does not need to hardcode all help text in a central place. Rather the help text for a command should be produced by the respective script. (Currently there is already an infrastructure of the sage-* scripts.

Developer commands should be separated from user commands.

Sage commands and their options

The following lists are not yet fleshed out completely. But before any implementation should happen, there should be an agreement on the interface.

User commands

(no command)
-v --version
  • Print version information.
help
  • Overview of all available commands.
gap
ditto
singular
ditto
spkg
  • Sage package handling (similar to Debian's dpkg or apt-get). That should install appropriate binaries for the respective machine.

    make should not be necessary on the user's machine.

run

Run the given file. (??? Shouldn't sage < file.sage >result.out do the same?

upgrade
Upgrade to a new version of Sage.

Developer commands

git
should be identical to calling git directly.
gdb
Run sage controlled by gdb.

Superfluous commands (because they are done via 'make')

The command sage should run Sage and not be misused for development processes. The make tool should deal with building Sage and its documentation

docbuild is superfluous. It's probably currently only called via sage, because SAGE_ROOT must be set.