Using superdoit without setting environment

[LisaAlmarode]

I want to use superdoit scripts such that they do not require the user to setup an environment (path and GemStone). It's a blocking limitation for end-user tools (that is, utilities that aren't only intended for use while working in a development environment).

This can be done by creating a copy of bin/superdoit_stone, and setting environment variables explicitly at the top of that script. Then, your superdoit script needs the full path, that is, starting line:
#!/usr/bin/env /benton3/users/lalmarod/GS64364/bin/lisa_superdoit_stone
This allows a simple.stone superdoit to execute. While it's limited in that there's hardcoded path/gemstone references, for tools that should be made available on a stable system it seems functional. Possibly there are things that don't work in this mode.

We should figure out how to support something like this.

[dalehenrich]

GsDevKit_home and it's someday successor GsDevKit_stones provide a registry of stone names so scripts can be run using xxx.stone ... -- <stone-name> or when run in the GsDevKit_stones stone directory itself xxx.stone ... ...

When setting $GEMSTONE is not practical (i.e., when you have multiple stones) I think the 'named stone" approach is pretty good ...

If you've set up a GsDevKit_home and the environment var $GS_HOME is defined, you can run superdoit scripts without having to monkey with setting an environment variable per stone ...

[LisaAlmarode]

The goal is for a complete outsider to be able to run a superdoit script, with no environment monkey business whatsoever.

[dalehenrich]

last night I had some thoughts about this issue I think that a viable alternative to setting an environment variable to "set the extent and/or stone and/or $GEMSTONE" is to to call another program expected to be found on your path: default_stone and default_solo ... these two shell(?) scripts could be changed with "returning" a $GEMSTONE, a ".topazini", and a solo extent" for any number of reasons ... and of course if there is no default_stone or default_solo in your PATH there is default behavior to be executed ... this script would be charged with making the decision of figuring out GEMSTONE/.topazini/soloExtent pluggable with or without env vars ... GsDevKit_home would put those scripts on the path and GsDevKit_stones would put those scripts on the path and $GEMSTONE/bin would have those scripts on the path ... and for your benton app, you would do the lisa_superdoit_stone magic in your set of scripts so you wouldn't have to change the .stone script itself to put the "lisa logic" into the lookup ...

There may be other alternatives to env var, but I think this is not totally bad 😃

[dalehenrich]

When you get a chance let's take a look at what I've been doing with GsDevKit_stones and superDoit ... at least for me it seems to push the right buttons 😄

I've made a fair bit of progress on _stones since last August ...

I also think that when we have an RPM distribution of GemStone, installation (for superDoit and _stones)

[JupiterJones]

GsDevKit_stones/bin/install.sh calls superDoit/bin/install.sh which doesn't exist.

[dalehenrich]

install.sh is in superDoit:v3 and GsDevKit_stones is now using superDoit v3.1 and the work I'm doing on GsDevKit_stones:v1.1 is aimed at superDoit:v3.1 and GemStone 3.7.0 ... I am making certain assumptions about Rowan features (mainly the ability to use https: urls to access Rowan load specs direcly from GitHub so they can be used to manage a set of git repositories like the GsDevKit eco system) ...

@JupiterJones I have been working on creating the stones registry and it is still evolving a bit, but if you've got time we could chat a bit about what I'm thinking/doing ... now is a good time for feedback :)