On Mar 4, 2012 3:12 AM, "Robert Bradshaw" <rober...@math.washington.edu>
wrote:
>
> 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"Maintaining things like `sage bu` because it's unambiguous would be a pain by hand, as would insuring that help text printed in a consistent manner. Less difficult would be insuring that all scripts would parse options appropriately (e.g. `sage build -tap4` vs `sage build --threads=4 -ta`), but still annoying. The purpose for my module is to insure uniformity from a user level, which thankfully means it doesn't need to do much (mainly the things I mention above). That is why most (if not all) of the current sage scripts will be easy to move over, and individual script dependencies would remain the same. > 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 -- 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
