Where does the $*REPO dynamic variable obtain its values, and how to change/alter them?

Question

This question is complementary to figuring out why this error (which started as a zef error) occurs.

Apparently, in certain circumstances the repository chain accessible from $*REPO may vary. Namely, in a GitHub action such as this one, where raku is part of a Docker image, all of a sudden the repository chain becomes:

(inst#/github/home/.raku inst#/usr/share/perl6/site inst#/usr/share/perl6/vendor inst#/usr/share/perl6/core ap# nqp# perl5#)

The first directory does not actually exist; this should be /home/raku/.raku instead. So a couple of questions

1. Why does rakudo install that unexisting directory as part of the repository chain
2. Is there any workaround that allows to simply change that value to the right one?

I don't really understand what's the cause for this happening. Initializing the container involves a long command line like this one:

/usr/bin/docker create --name d043d929507d4885927ac95002160d52_jjmereloalpinerakugha202110_1e6e32 --label 6a6825 --workdir /__w/p6-pod-load/p6-pod-load --network github_network_da048828784a46c3b413990beeaed866  -e "HOME=/github/home" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work":"/__w" -v "/home/runner/runners/2.285.1/externals":"/__e":ro -v "/home/runner/work/_temp":"/__w/_temp" -v "/home/runner/work/_actions":"/__w/_actions" -v "/opt/hostedtoolcache":"/__t" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" --entrypoint "tail" jjmerelo/alpine-raku:gha-2021.10 "-f" "/dev/null"

Where, effectively there seems to be an environment variable set to that value. So it might be that the environment variable HOME is the one that determines that, instead of whatever happened in the installation. But I don't know if that's a feature, or a bug.

Answer 1

You need to set RAKULIB to wherever your libraries were initially installed, as is done here:

# Environment
ENV PATH="${WORKDIR}/.raku/bin:${WORKDIR}/.raku/share/perl6/site/bin:${PATH}" \
    ENV="${WORKDIR}/.profile"\
    RAKULIB="inst#/home/raku/.raku"

This part is underdocumented, but the inst# prefix reflects the fact that it includes precomp units, and the directory is where it was initially installed. Thus, no matter where HOME is, Rakudo will always find the original installed modules.

---

Original answer

I don't have an answer to the second part, but I can answer the first part: the first element in the repository chain is taken from $HOME every time rakudo is started up. If the value of $HOME when zef or any other module was installed was different from the current one (case in point), one workaround would be do something like

HOME=/home/raku zef --version

Maybe create a shell function or an alias that does so, if you don't want to carry around the variable that way. Long term solution, really no idea.

Answer 2

Why does rakudo install that unexisting directory as part of the repository chain

Because you set $HOME to that directory. Unsurprisingly the home repository references $HOME.

Is there any workaround that allows to simply change that value to the right one?

This doesn't need to be worked around, rather your environment needs to be setup properly. It appears you change $HOME to a non-existent directory, try to get zef to install to this new directory implicitly (which even if it did exist it probably wouldn't have permissions without you having done so), and when that failed you installed to /home/raku explicitly and wonder why your raku environment with a /github/home home directory/repo doesn't look in /home/raku (and how could it?). My suggestion is to figure out your file permission issues when you setup the new $HOME directory.