fix: use shell-specific conda activation and check conda init status (Fixes #1313)

[karthiknadig]

Summary

Fix conda activation on non-Windows systems (Linux/macOS/WSL) to use shell-specific activation commands instead of a generic source activate for all shells. Adds Fish shell support and checks shell profiles to determine if conda init has been run.

Changes

• Shell-specific activation on non-Windows (nonWindowsGenerateConfig):

  • Bash/ZSH/SH: source conda.sh + conda activate, falls back to source activate <env>
  • Fish: source conda.fish + conda activate, falls back based on conda init fish status
  • PowerShell: use conda-hook.ps1 + conda activate, falls back based on conda init powershell status
  • When no sourcing script is found and conda init hasn't been run, uses the full conda path (gives an actionable error)
  • When conda init has been run, uses bare conda (shell function is set up on startup)

• Shell profile conda init detection (checkCondaInitInShellProfiles):

  • Scans .bashrc, .zshrc, config.fish, PowerShell profiles for conda initialize blocks
  • Respects XDG_CONFIG_HOME for Fish and PowerShell paths
  • Checks Fish conf.d/conda.fish (newer conda places init there)

• Fish shell sourcing script discovery (getCondaFishPath):

  • Searches etc/fish/conf.d/conda.fish, shell/etc/fish/conf.d/conda.fish, Library/etc/fish/conf.d/conda.fish

• Added Fish to ShellSourcingScripts interface and generateShellActivationMapFromConfig

Tests

• 11 tests for checkCondaInitInShellProfiles (conda init detection per shell, XDG_CONFIG_HOME, multiple shells)
• 12 tests for nonWindowsGenerateConfig (shell-specific activation, init status fallback, deactivation)

Related

• Fixes Conda Error caused by wrong activate command #1313
• PET issue for cross-OS conda discovery in WSL: PET conda locator fails to find conda manager for Windows conda installations accessed via WSL /mnt/ paths python-environment-tools#369

[Copilot]

Pull request overview

This PR fixes conda environment activation on non-Windows platforms by generating shell-specific activation commands (including Fish) and by detecting whether conda init <shell> has been run via scanning common shell profile/config files. This addresses incorrect activation behavior (notably for Fish in WSL/Linux/macOS).

Changes:

• Updated non-Windows conda activation generation to use shell-specific init scripts (conda.sh, conda.fish, conda-hook.ps1) and fallbacks based on detected conda init status.
• Added shell profile scanning to detect conda init blocks and persisted the results in conda sourcing status.
• Added new unit tests covering shell-init detection and non-Windows activation command generation (including Fish).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/managers/conda/condaUtils.ts	Switches non-Windows activation to shell-specific command sequences and adds Fish support in activation maps.
src/managers/conda/condaSourcingUtils.ts	Adds Fish sourcing script discovery and implements conda init detection via shell profile scanning.
src/test/managers/conda/condaUtils.nonWindowsActivation.unit.test.ts	Adds unit tests validating non-Windows shell-specific activation behavior across bash-like shells, Fish, and PowerShell.
src/test/managers/conda/condaSourcingUtils.shellProfiles.unit.test.ts	Adds unit tests validating conda init detection across bash/zsh/fish/pwsh and XDG config overrides.

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

For ShellConstants.SH, the activation command uses source ..., but POSIX sh (e.g., dash) typically does not support source (it uses .). This will cause activation to fail when the user’s integrated shell is sh. Consider generating a separate activation sequence for sh that uses . (dot) instead of source (both for sourcing conda.sh and for the activate fallback).

[Copilot]

PowerShell activation runs the hook script by placing the .ps1 path directly in executable. If the path contains spaces, the command builder will quote it, and in pwsh a quoted path is treated as a string (not invoked) unless prefixed with the call operator &. To make this robust, consider emitting the first PowerShell command as & <condaPs1Path> (e.g., executable: '&', args: [condaPs1Path]) rather than executable: condaPs1Path.

Suggested change

	pwshActivate = [{ executable: condaPs1Path }, { executable: 'conda', args: ['activate', envIdentifier] }];
	pwshActivate = [
	{ executable: '&', args: [condaPs1Path] },
	{ executable: 'conda', args: ['activate', envIdentifier] },
	];