fix: add reactivation to pixi shell

[wolfv]

TODO:

• implement for bash
• implement for fish

fixes #326 #977

[pavelzw]

not sure i like this behavior :/ seems a bit too hacky

[wolfv]

@pavelzw unfortunately there is not really a way around it and it's exactly what conda/mamba/micromamba do. The re-hashing is the crucial step...

[pavelzw]

Using direnv with watch_file pixi.lock should fix this issue.

[wolfv]

yeah, but not everyone uses direnv 😱 I think the change is reasonable enough, and also does something in pixi shell.

[pavelzw]

I guess if this is the most magic that it's getting and the shell hook is not used globally but only for pixi shell this change is okay...
Alternatively you could try to catch if pixi add ... is happening inside of pixi shell and if so print

please reload your environment by executing
    eval "$(pixi shell-hook)"

Not sure if this is much better than adding a shell function for pixi, though.

[baszalmstra]

I do agree that this is a bit magic but I also dont see another way to solve this other than only printing a warning.

At the moment this now only works for shells other than zsh and bash. What if we add a check to pixi add and co to see if you are in a shell and print a warning if thats the case? That requires no magic and should help people that use better shells for which no magic is (yet) implemented.

[wolfv]

I also tested this with fish and nushell and both do not seem to have the same problem as bash & zsh.

I did not test on Windows with

• git bash
• powershell
• cmd.exe

Not sure if these have the problem or not. In any case, even without testing those, I think it's a good change.

[wolfv]

I think as it stands it's a "strict improvement" over the current state.
I would like to investigate complete shell restart on these commands (ideally when we see that e.g. the lockfile has changed).
I think on UNIX that would be possible.

However, IMO we can merge this, open a new issue, and take it from there.