I've created a repo on github: github.com/ohanar/sagescripts
Much of the backbone has been setup, although I've ported very few
actual scripts (the ones there are mainly to test that my generating
code actually does what I want it to).
The way it is setup is pretty basic:
Scripts will still be written in bash and python (located in the
src/bash and src/python directories respectfully), however, command
line options and help text are separated from the scripts.
Instead, to include a script in sage, an entry to src/scripts_setup.py
is needed, as well as providing command line options and help text.
The scripts in src/{bash,python} can assume that certain variables
will be set w.r.t. the command line options (better description to
come :) ).
Currently there is quite a bit of missing functionality (python
scripts, scripts that won't be accessible as a subcommand of sage,
help printing for some subcommands, etc), and the syntax/names of
src/scripts_setup.py is not ideal, however, moving over most bash
scripts should be relatively easy at this point in time.
Also, I would like to decouple the sage-scripts spkg from sage
releases, since in many cases it seems like the only change is a
version bump. I've added SAGE_VERSION and SAGE_RELEASE_DATE to
sage-env, which can hopefully remedy this.
-----
Pertaining to the whole `sage script.sage` vs `sage run script.sage`,
what if made a default mode -- if we cannot match $1 to any sage
subcommand (or ambiguity thereof), then sage-run would be called with
$@. This would also be nice for `sage pkg` where we could set the
default command to install (since that will be the most common use of
`sage pkg`).
As for #!'ing stuff, `sage foo` can also be called as `sage-foo`, so
long as the scripts are in PATH, SAGE_ROOT is set, and foo is not just
an external program (such as python or sqlite3).
On Fri, Mar 2, 2012 at 02:46, Robert Bradshaw
<rober...@math.washington.edu> wrote:
> On Fri, Mar 2, 2012 at 1:27 AM, Jason Grout <jason-s...@creativetrax.com>
> wrote:
>> On 3/2/12 2:55 AM, Robert Bradshaw wrote:
>>>
>>> I think sage foo ... should default to running bin/sage-foo (in the
>>> sage environment) if it exists, and treat foo as a file otherwise.
>>> Virtually no argument parsing (aside from understanding --) would be
>>> involved here, and the decision to use bash/python/... would be
>>> delegated to the subscripts. "sage sh ..." would be sufficient for the
>>> "-C" option suggested, but "sage gap" and "sage gp" etc. would be
>>> natural to have directly. "sage run" could be provided to treat its
>>> argument(s) as files too.
>>
>>
>> -1 to magic parsing of 'sage foo'. What if sage-foo was later added to
>> sage? Then things would break for people.
>
> This is true regardless of the calling mechanism. Subcommands should
> be added with care. I wasn't proposing calling "foo" for any foo in
> the sage-environment path.
>
>> I like the idea of 'sage run foo' to run foo. How would that be added to a
>> script file, though?
>>
>> #!/path/to/sage/sage run
>> do some commands
>
> I think we still need to keep "sage path/file.sage" around. The
> hash-bang convention is convenient, but limited.
>
> - Robert
>
> --
> 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
--
Andrew
--
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
