On Sat, Mar 3, 2012 at 3:21 PM, R. Andrew Ohana <andrew.oh...@gmail.com> wrote:
> 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.If I understand right, you're proposing replacing our scripts with a custom bash script-generator that passes arguments to other shell scripts via command line variables? And creating subcommands would require a mix of bash, your custom module, and Python? This seems like an unnecessarily complicated layer of abstraction. Why not let the top-level sage script just set up the environment and dispatch to the (again ordinary shell or python or ...) sage-subcommand executable? All you need is a subcommand -> script mapping (or just a list of valid subcommands, if the mapping is consistent). Perhaps "sage help subcommand" could become "sage subcommand --help" but in general the logic should be quite simple, and I think this would be both more flexible and easier to follow/develop/debug. > 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). Sure. > 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 -- 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
