Remove base environment PATH components from conda run environment

[jezdez]

Fix #11174.

[jezdez]

This'll need to be changed back to master, but is needed since the addition of /opt/conda/bin to PATH in the Dockerfile below made testing this impossible.

[kenodegard]

I don't think this is the fix we want. This change will blindly remove the base env in all scenarios which would be problematic when stacking environments (either via auto_stack >= 1 or conda activate --stack).

In non-stacked cases (see Case 1 & 2) this fix will correctly handle the problem but in stacked cases (see Case 3) this fix will incorrectly strip out the stacked base env.

Case 1: No environments activated (I think we all agree with this one)

$ conda run -n haspy which -a python           # expect haspy python
$CONDA_ROOT/envs/haspy/bin/python
/usr/bin/python

$ conda run -n notpy which -a python           # expect system python
/usr/bin/python

Case 2: auto_stack: 0 (default behavior, here too I think we are in agreement)

# activating base
$ conda activate base
(base) $

(base) $ conda run -n haspy which -a python
$CONDA_ROOT/envs/haspy/bin/python
/usr/bin/python

(base) $ conda run -n notpy which -a python
/usr/bin/python

# activating haspy, no stacking
(base) $ conda activate haspy
(haspy) $

(haspy) $ conda run -n haspy which -a python
$CONDA_ROOT/envs/haspy/bin/python
/usr/bin/python

(haspy) $ conda run -n notpy which -a python
/usr/bin/python

Case 3: auto_stack: 1+ or conda activate --stack ENV

# activating base
$ conda activate base
(base) $

(base) $ conda run -n haspy which -a python    # expect haspy python
$CONDA_ROOT/envs/haspy/bin/python
$CONDA_ROOT/bin/python
/usr/bin/python

(base) $ conda run -n notpy which -a python    # expect base python
$CONDA_ROOT/bin/python
/usr/bin/python

# activating haspy, with stacking
(base) $ conda activate haspy
(haspy) $

(haspy) $ conda run -n haspy which -a python   # expect haspy python
$CONDA_ROOT/envs/haspy/bin/python
$CONDA_ROOT/bin/python
/usr/bin/python

(haspy) $ conda run -n notpy which -a python   # expect haspy python
$CONDA_ROOT/envs/haspy/bin/python
$CONDA_ROOT/bin/python
/usr/bin/python

I noticed two interesting things:

1. when conda activate/deactivate is called it is only replacing the first prefix match, see conda.activate._Activator._replace_prefix_in_path
2. our PATH is already mangled at the very start of the conda import (i.e. add print(os.environ["PATH"]) at the top of conda/__init__.py and it lists the current $CONDA_PREFIX twice but echo $PATH only shows it once), this duplication is happening in our shell interface:

   • conda/conda/shell/etc/profile.d/conda.sh

     Lines 27 to 30 in cb97f86

     	__conda_exe() (
     	__add_sys_prefix_to_path
     	"$CONDA_EXE" $_CE_M $_CE_CONDA "$@"
     	)

     conda/conda/shell/etc/profile.d/conda.sh

     Lines 4 to 25 in cb97f86

     	__add_sys_prefix_to_path() {
     	# In dev-mode CONDA_EXE is python.exe and on Windows
     	# it is in a different relative location to condabin.
     	if [ -n "${_CE_CONDA}" ] && [ -n "${WINDIR+x}" ]; then
     	SYSP=$(\dirname "${CONDA_EXE}")
     	else
     	SYSP=$(\dirname "${CONDA_EXE}")
     	SYSP=$(\dirname "${SYSP}")
     	fi
     	if [ -n "${WINDIR+x}" ]; then
     	PATH="${SYSP}/bin:${PATH}"
     	PATH="${SYSP}/Scripts:${PATH}"
     	PATH="${SYSP}/Library/bin:${PATH}"
     	PATH="${SYSP}/Library/usr/bin:${PATH}"
     	PATH="${SYSP}/Library/mingw-w64/bin:${PATH}"
     	PATH="${SYSP}:${PATH}"
     	else
     	PATH="${SYSP}/bin:${PATH}"
     	fi
     	\export PATH
     	}

   • conda/conda/shell/condabin/conda.bat

     Line 25 in cb97f86

     @SET PATH=!_sysp!;!_sysp!\Library\mingw-w64\bin;!_sysp!\Library\usr\bin;!_sysp!\Library\bin;!_sysp!\Scripts;!_sysp!\bin;%PATH%

So I'm thinking that we need to be looking into understanding why the prefix is being re-injected into the PATH prior to calling conda.

[jezdez]

Well, #8528 added __add_sys_prefix_to_path and doesn't say a word why except for pointing to a number of tickets, which seem to be regression tickets for stuff that was broken in 910a7ee. Super messy changes and so little explanation in public tickets :(

[jezdez]

We've talked a bit more and think this is best solved differently by looking at the changes made in #8528. Given that the ticket #11174 isn't the highest priority we shouldn't block the 4.12.0 release, either.

@kenodegard in case you find anything new, feel free to reopen of course!