-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
run deactivate.d scripts for global installed tools #1957
Comments
Thanks for reporting. Would you be interested to open a PR for that? |
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. |
Good question, if don't do it yet, then we should start doing it. |
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? |
Variables set in the recipes should be repected! |
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? |
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! |
Thanks for confirming |
Problem description
I noticed that when a tool is installed with global, binary wrappers are created that first set paths and then run activate.d scripts before running the program. However, these binaries do not run the deactivate.d scripts after running the wrapped program.
Adding this would be really helpful for scripts that need to replace an environment variable before running, and then replace it with the original afterwards. For example, many tools need to clear the PYTHONPATH variable before running, and then change it back with what was there afterwards. The current way global scripts are installed, this doesn't happen and the variable stays cleared. Adding calls to any deactivate.d scripts after would solve this. Thanks!
The text was updated successfully, but these errors were encountered: