Fix #87: Create facility for sourcing scripts from projects

[e-carlin]

As I was adding the scripts I was wondering if they should just be pkcli's in sirepo? Maybe odd to create this other structure...

[robnagler]

pkcli has the advantage of being able to access configuration. However, this is a bootstrap problem: the environment may not be setup yet. I think a file is best.

[robnagler]

Where would the variable be set?

One way we can do this is by setting some global state in sirepo-dev. We have used /vagrant as a flag, but that's not good. Rather, I think it even could be something in /rsmanifest.json. We should be able to control it with environment so we can test this with CI.

If so, it creates a discoverability problem and more headache when setting up to get the environment just right.

I think we have the advantage of being policy rich. We can say that if you are developing sirepo, you get these functions only if you use sirepo-dev to setup your environment.

[e-carlin]

One way we can do this is by setting some global state in sirepo-dev

That sounds fine. Set bivio_want_aux_src_env=1 in ~/.pre_bivio_bashrc?

This won't work in devbox because we don't call sirepo-dev there. We're moving away from devbox so maybe that's fine? It would be challenging to call sirepo-dev in devbox (ex yum installs) so another reason to move away from devbox.

you get these functions only if you use sirepo-dev to setup your environment

👍

[robnagler]

That sounds fine. Set bivio_want_aux_src_env=1 in ~/.pre_bivio_bashrc?

Well, now we are really going down the rabbit hole. We need to add ~/.bashrc.d, which of course means we have to somehow define the ordering. If we had started with this instead of an ever increasing list of names, it would have been easier for us to manage. I still think we should do it. This is not right:

    for f in \
        "$HOME"/jupyter/.pre_bivio_bashrc \
        "$HOME"/.pre_bivio_bashrc \
        /etc/bashrc \
        "$HOME"/src/*/home-env/bashrc.d/*.sh \
        "$HOME"/.post_bivio_bashrc \
        "$HOME"/jupyter/.post_bivio_bashrc \
        ; do

We need to respect existing bashrcs. However, the goal would be to migrate to an organized system (nn-prev-bivio.sh, mm-jupyter.sh, etc.). The files in home-env/bashrc.d/*.sh would get symlinked so that users can know the absolute ordering.

sirepo-dev would deposit a symlink from ~/.bashrc.d/71-sirepo.sh to ../src/radiasoft/sirepo/etc/home-env.sh. Then we would modify the above for:

        /etc/bashrc \
        "$HOME"/src/*/home-env/bashrc.d/*.sh \
        "$HOME"/.bashrc.d/*.sh \

Then create a new issue to clean up ~/.bashrc so that it does the right thing.

I used 71 above for a reason. It allows modularity. "apps" can install in 3n and 7n. Users control 0n and 9n. home-env controls 1n, 5n, and 8n. Something like that.

This won't work in devbox because we don't call sirepo-dev there.

We can share the code in the image builder. It could be called sirepo-dev-home-env, and gets called from sirepo-dev and devbox build.

[e-carlin]

Maybe we need a call but I don't understand why adding bashrc.d is advantageous. It has a few costs: It is work to move to the bashrc.d model and we would have to update both home-env and sirepo-dev whenever we want to add a new repo that contains home-env.sh. In addition it doesn't follow our existing model that users can set env to turn features on and off. Instead they'd have to know that sirepo-dev set some symlinks and they'd have to remove them (and run sirepo-dev to get them back). Seems a bit odd to me.

[e-carlin]

Decided to not build this infra. Commands are just pkcli's