Shell hooks are not installed when running `zsh --login`

I found this issue working with Hermit in VS Code. When we launch VS Code from a hermit-activated environment/shell, it fails to set the PATH correctly for the underlying terminal:

source ./bin/activate-hermit
echo $HERMIT_ENV                       # /path/to/my/repo
which python3                          # /path/to/my/repo/bin/python3

Which tells me that the environment is activated successfully, however, if I open a VS Code instance from that terminal:

code /path/to/my/repo

And try to use the integrated terminal:

echo $HERMIT_ENV                       # /path/to/my/repo
which python3                          # /usr/bin/python3

Which means that HERMIT_ENV is propagated, but PATH is not propagated correctly.
To fix this, I have to activate it again from the integrated terminal, even though it is using zsh, which has the right hermit shell-hooks in .zshrc:

source ./bin/activate-hermit

This Hermit environment has already been activated. Skipping

I then get this confusing message, however, the shell is configured correctly now:

which python3                          # /path/to/my/repo/bin/python3

I wonder if there is a better way to detect this better than using HERMIT_ENV. We can either:

fix this for integrated terminals, so that PATH is propagated correctly.
Detect that the shell is not truly configured, and update error message accourdingly.

I would imagine that VSCode is overwriting your PATH, there's not much we can do about that IMO, unless you have any suggestions.

TBH I think ideally there would be a VSCode Hermit plugin.

useShellEnvironment

Nice find! We should add that to the docs.

It looks like VSCode is messing with the PATH. With that setting I get the following:

/Users/aat/bin:/opt/homebrew/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/usr/local/munki:/Users/aat/Development/orc/bin:/Users/aat/Development/orc/build:/Users/aat/Development/orc/scripts:/Users/aat/Development/orc/node_modules/.bin:/Users/aat/Development/orc/.hermit/node/bin:/Users/aat/Development/orc/.hermit/go/bin:/Users/aat/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Applications/kitty.app/Contents/MacOS:/opt/homebrew/opt/fzf/bin

So it's moving the system PATH entries before my custom ones, which makes little sense to me TBH. Anyway, unless there's something straightforward, I don't think we should expend significant time on fixing what IMO is a misfeature of VSCode. Suggestions welcome though.

BTW I fired up Sublime and it actually exhibits the same behaviour. Also in VSCode the shell hooks are disabled.

Some more data. It looks like --login does not bring in the shell hooks (cc @jvmakine)

🐚 ~/Development/orc $ zsh -l
~/Development/orc $ cd
~ $ cd -
~/Development/orc
~/Development/orc $

So, I think there are a couple of different issues that are mentioned here:

Hermit's inability to detect whether the shell is truly deactivated or not (which is different than if the environment variables are set). I can use type deactivate-hermit to detect that, which should evaluate to false if the shell is not set correctly. However, it is useless if hermit itself is not doing that, as it will still error out with:

This Hermit environment has already been activated. Skipping

Should it detect the shell activation using something like this instead of relying on environment variables? In my understanding, they are separate things (you can have hermit binaries in your PATH, without ever using shell hooks).

VS Code inability to detect hermit tools, which should be fixed by doing a proper Hermit VS Code extension (using the API above, or even EnvironmentVariableMutator). I've used the VS Code APIs before, and happy to have a discussion around that later, but I think this is a much bigger work item than the issue above.

I don't think this is true:

Hermit's inability to detect whether the shell is truly deactivated or not

In my example above, the environment is set - all of Hermit's envar changes are active - but something is reordering the $PATH. I suspect your original issue is the same, that you have python3 installed on your system and this path reordering is causing that to be used. The PATH reordering is the real issue that needs to be solved.

I see. I will dig deeper then. Thanks for the tip.

I think something like the following would be a good workaround for vs code at least.

# Workaround for Visual Studio Code integrated terminal
if [[ -v ACTIVE_HERMIT && -v VSCODE_GIT_IPC_HANDLE ]]; then
    unset ACTIVE_HERMIT
    source bin/activate-hermit > /dev/null
fi

Alternatively we can have the ./bin/activate-hermit script still activate the shell commands if it detects they are missing.

Can we reopen this issue, or should we make a new one?

Moving my earlier comment here:

@damienrj @alecthomas I think a good fix for the error message (and the activation error) is to just refactor activate-hermit, by just moving this method (and possibly the others) to the top of file, before the code that uses them. The bug is that it is called before it is defined, which causes a runtime error:

hermit/shell/files/activate.tmpl.sh

Line 43 in 5aaecb9

deactivate-hermit() {

The fix is relatively simple/safe to do, but I didn't get time to write a shellspec full integration test for it.

This won't fix the PATH issue (so you still need to activate again inside the terminal), but I argue that it would be a minor inconvenience at this point, and the rest should be working.

@OmarTawfik #268 let's get it going!

The reason deactivate-hermit is called before being defined is for backwards compatibility. Because of continuous upgrades, Hermit has to basically support a form of "schema evolution".

In this case that means that if a new version of Hermit is installed that modifies how deactivate-hermit operates, we want the previous logic to be applied, not the new logic.

We could instead check if it's defined before calling it.

Yeah that seems reasonable to me.