mise activate not workings with --shims flag ?

[tony-sol]

I've tried to use direnv-ish functional of mise and faced with strange behaviour. Previously i only used mise for tools versions management and this

source <(mise activate zsh --shims)

in $ZDOTDIR/.zshrc worked fine (as i thought so).

But while trying to use env, i figured out, that mise doctor will keep saying activated: no until i changed activation line to

source <(mise activate zsh)

Next, i've tried to figure out what exactly activation does and found this:

so mise activate zsh --shims is empty.
Okay, that's strange, but what's next - right after activate without shims-flag - there is output:

BUT!! - $PATH has been already modified while activation and another activate --shims will just add Yet Another path and report a problem:

1. shims are on PATH and mise is also activated. You should only use one of these methods

In my understanding, these features aren't mutually exclusive - e.g. i set up $MISE_SHIMS explicitly AND put in into $PATH explicitly as well (cause i need to keep a specific paths order), so i don't need $PATH to be modified, BUT i also want to have env and hooks features, provided by activation.

So is there any recipes/hacks/workarounds to achieve that?

[tony-sol]

long and the short - is there a way to active mise, without modifying $PATH, except really dirty hacks like this

source <(mise activate zsh) && export PATH="$(__calling_my_path_builder_function_again)"

[tony-sol]

I was wrong, even though mise activate zsh has export PATH in the beginning, hacks like this

source <(mise activate zsh | grep --invert-match --extended-regexp '^export PATH=')

don't work and if your PATH already has MISE_SHIMS, mise doctor would say

version: 2024.12.22 macos-arm64 (2024-12-30)
activated: yes
shims_on_path: yes
...
settings:

1 problem found:

1. shims are on PATH and mise is also activated. You should only use one of these methods.

and still activation modifies PATH

[syhol]

If you run activate without sourcing you can see this function that sources the result of hook-env:

_mise_hook() {
  eval "$(/Users/simon/.local/bin/mise hook-env -s zsh)";
}

This is what sets the path, and this function is called in a few places.

So this is where you need to apply your | grep --invert-match --extended-regexp '^export PATH='

You could save that entire output down to a file like my-local-zsh-activate.zsh and add the grep to that function and delete the PATH:

_mise_hook() {
  eval "$(/Users/simon/.local/bin/mise hook-env -s zsh | grep --invert-match --extended-regexp '^export PATH=')";
}

Then source it instead:

source my-local-zsh-activate.zsh

Or skip the separate file and edit it on the fly with sed:

source <(mise activate zsh | grep --invert-match --extended-regexp '^export PATH=' | sed "s/hook-env -s zsh/hook-env -s zsh | grep --invert-match --extended-regexp '^export PATH='/g")

[tony-sol]

Hmm, i saw mise activate zsh output and saw mise hook-env there, but didn't think that there are several PATH exports
I'll research this more closely, thx

[syhol]

Some more context here: https://mise.jdx.dev/faq.html#what-does-mise-activate-do

[jdx]

cause i need to keep a specific paths order

what does this mean? mise activate respects the PATH order and injects entries into the point it was activated

[jdx]

my point is that I think it's dirty only because you're trying to put it all on a single line, I think if you put it on multiple it won't look so bad. Of course this is cosmetic and subjective though.

i don't really understand how these thing are connected.

because it's documented that mise activate --shims only adds the shim directory to PATH and nothing more. There are also technical reasons like you need to be able to put it into your login shell or possibly zshenv and mise has to be super simple. Shims can be thought of as a "compatibility mode" where not much can happen. If someone used mise activate --shims and mise put in chpwd logic that executes hooks—inside of a zshenv script it may very well call mise again which can call zsh and cause a loop.

[syhol]

I wouldn't consider splitting your prepend_path to be dirty. Also shims are arguably slightly less reliable than activate, so if you have the option to avoid it then it's another win.

[tony-sol]

because it's documented that mise activate --shims only adds the shim directory to PATH and nothing more

i think i got the point, but this seems to me not quite obvious. I mean it seems something wrong in naming this way, imho after your explanation, mise shims would be more clear and transparent

[syhol]

I'll update the docs to more clear about this behavior

[tony-sol]

i don't think this dirty because i'm "trying to put it all on a single line", but because this hack implies multiple exporting of same variable, which increases first command lag and first prompt lag a bit.
Not dramatically, but still
Between this

# ...
__append_to $PATH "${HOMEBREW_PREFIX}/bin"
__append_to $PATH "${HOMEBREW_PREFIX}/sbin"
source <(mise activate)
__append_to $PATH $GEM_BIN
__append_to $PATH $GOBIN
__append_to $PATH $XDG_BIN_HOME
# ...

and this

__append_to $PATH "${HOMEBREW_PREFIX}/bin" "${HOMEBREW_PREFIX}/sbin"
source <(mise activate)
__append_to $PATH $GEM_BIN $GOBIN $XDG_BIN_HOME

i'd choose second one for the good of performance despite the fact that first one is more readable and looks more pretty (and i completely agree with that).
There is somewhere a line between code beauty and it's performance and mine is here :)

Thank you all for helping <3

[tony-sol]

Resume:

• source <(mise activate zsh --shims) only adds the shim directory to PATH and nothing more, if you add MISE_SHIMS into PATH manually, there is no need to call activate with --shims flag
• source <(mise activate zsh) adds its entries at the begining of PATH, if you need full control over entries order in your PATH, you should call source <(mise activate zsh) in place where your PATH built