@AntoinePrv Yes. The originally implementation unset the path variable to empty string which caused some obvious issues for me when deactivating. I see that the current PR is entangled with the other PR I will fix that and look at the review above.

I don't understand the practice with catch(...) { }. If failure is not an issue, why do it in the first place?
at least using a log like LOG_WARNING << "Failed to create directory: " << ...; would let user know what went wrong (and maybe recover/investigate themselves.

As an implementation catch(...) is also a bad design, we should prefer catch(const fs::filesystem_error &). According the the reference, this function could also throw std::bad_alloc, which we have no reason to silence.

I don't understand the practice with catch(...) { }. If failure is not an issue, why do it in the first place? at least using a log like LOG_WARNING << "Failed to create directory: " << ...; would let user know what went wrong (and maybe recover/investigate themselves.

As an implementation catch(...) is also a bad design, we should prefer catch(const fs::filesystem_error &). According the the reference, this function could also throw std::bad_alloc, which we have no reason to silence.

I'm just following the example listed above. In essence we can remove the entire section since the activation does not generate any files. EDIT: this is also not the core of the current PR. The part being commented on was already merged before.

This works great on my machine (deactivation works as expected); however, I did end up commenting out the prompt modification in $env.config-path as it clobbered my existing prompt:

# # update prompt
# if ($env.CONDA_PROMPT_MODIFIER? != null) {
#   $env.PROMPT_COMMAND = {|| $env.CONDA_PROMPT_MODIFIER + (create_left_prompt)}
# }

# # update prompt
# $env.PROMPT_COMMAND = {|| create_left_prompt}

I am using Starship, which already picks up on an activated environment and uses the following to inject the prompt:

mkdir ~/.cache/starship
starship init nu | save -f ~/.cache/starship/init.nu

source ~/.cache/starship/init.nu

so it might just be an issue of a nonstandard config

@zacharyburnett ah I was afraid of that happening to someone. I haven't figured out a good way to extend a closure. Starship seems to additionally override it (see here), implying it is no straightforward (embedded way to do it). I will give this some thought.

@zacharyburnett can you checkout the latest push. I believe this may be compatible with starship, and other future prompts.

@zacharyburnett can you checkout the latest push. I believe this may be compatible with starship, and other future prompts.

I reran micromamba shell init --shell nu and it works great now, thanks!

That is good to hear ;-)

Can this be merged @AntoinePrv?

Please excuse me for not being very responsive, I'm not very knowledgeable with Nushell.
If it works for both of you, I guess we can merge (waiting for CI once more).

For the prompt, I was never a big fan of Conda modifying the prompt, but it did not matter since advanced bash/zsh prompts are set through PROMPT_COMMAND.
If you want to leave the prompt out of the activation script here, that is also fine. Since Nushell is more powerusers, I expect users like to set their own prompts.