On Sun, Mar 4, 2012 at 3:48 AM, R. Andrew Ohana <andrew.oh...@gmail.com> wrote:
>
> 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.But there are already standard packages like optparse that handle this nicely (and have the advantage that the flags and help are contained in the relevant script itself). It would be a bit more manual work for commands that need to be in shell scripts, but not too bad (and those are likely the simpler ones) and likely simpler than using a custom script-generator. Also, we shouldn't be doing any argument parsing or help strings for subcommands like hg, gap, cython, ... (probably the majority of them in fact), as that's best done by the subordinate binary. > 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 -- 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
