run deactivate.d scripts for global installed tools about pixi

[Hofer-Julian]

Thanks for reporting.
Ideally, we wouldn't use bat scripts anymore mid-term, but until then I agree that we should run the deactivate script.

Would you be interested to open a PR for that?

[alexweisberg]

Thanks for looking into it! I'm not familiar with the pixi code base so it may have to be someone else.

On a related note, I haven't checked, but are environment variables set/respected for global installed tools by default? Conda 4.9 and later supports setting these in the meta.yaml recipe variables section. I ask because I developed a conda package that sets and unsets a specific environment variable for the tool in the activate.d and deactivate.d scripts, but I may update it to use the recipe instead since that would be safer.

[Hofer-Julian]

Good question, if don't do it yet, then we should start doing it.

[baszalmstra]

Im not quite sure I understand because the tools also start a new shell, so any variables set only persist with the tools environment doesnt it?

[baszalmstra]

Variables set in the recipes should be repected!

[alexweisberg]

Great! and yes, in a new shell it does not matter. But I was thinking more for 'global' installed tools where it appears that a shell is not activated to run the program.

[Hofer-Julian]

Great! and yes, in a new shell it does not matter. But I was thinking more for 'global' installed tools where it appears that a shell is not activated to run the program.

Could you give a small reproducer, where the environment is modified after running a binary installed by pixi global?

[alexweisberg]

I just tested my example and because the activate scripts were run in a bash script, the environment changes don't persist after the script is finished running. So there is no need to run the deactivate.d scripts if the only things modified by them are environment variables. My apologies!

[Hofer-Julian]

Thanks for confirming