Allow `conda/analysis3` environments to be properly activated from a VSCode jupyter kernel

[atteggiani]

This issue was found after being reported in this forum post.

This issue is based on the analysis3-25.09 version, but its applicable to any other version as well.

Overview

When running a kernel for a conda/analysis3 environment from VSCode (using the Jupyter VSCode extension) after having specified a conda/analysis3 version Python exe as the Python interpreter (using the Python VSCode extension), the following error is shown:

ERROR 1: PROJ: proj_create_from_database: Open of /g/data/xp65/public/./apps/med_conda/envs/analysis3-25.09/share/proj failed

Minimal Error reproduction

The error can be reproduced from a Gadi terminal by running:

/g/data/xp65/public/apps/med_conda_scripts/analysis3-25.09.d/bin/python3 -c "import cartopy"

Reason of the error

The reason of this error is to be found in the PROJ_DATA env variable, used by the PROJ C library (called as a dependency of cartopy above). When this env variable is not set, the error gets triggered.
When a conda/analysis3 module gets loaded, the PROJ_DATA env variable gets set.
To confirm this, you can run the following on Gadi:

unset PROJ_DATA
echo $PROJ_DATA
# <Blank line>
module use /g/data/xp65/public/modules/ 
module load conda/analysis3-25.09
echo $PROJ_DATA
# /opt/conda/analysis3-25.09/share/proj

The same happens when the internal python environment gets activated within the singularity container.
To confirm this, you can run the following on Gadi:

/g/data/xp65/public/apps/med_conda_scripts/analysis3-25.09.d/bin/launcher.sh bash

and inside the singularity container:

echo $PROJ_DATA
# <Blank line>
. /g/data/xp65/public/apps/med_conda/envs/analysis3-25.09/bin/activate
echo $PROJ_DATA
# /g/data/xp65/public/apps/med_conda/envs/analysis3-25.09/share/proj

Note the /g/data/xp65/public/apps/med_conda/envs/analysis3-25.09/share/proj folder is a symlink to /opt/conda/analysis3-25.09/share/proj.

What should happen instead

This should work when a Jupyter kernel gets activated, because when selecting a kernel VSCode tries to activate the related environment.
However, from the VSCode Python output, when selecting an analysis3 kernel, the environment activation attempt is performed by sourcing the activation file:

. /g/data/xp65/public/apps/med_conda_scripts/analysis3-25.09.d/bin/activate ...

However, due to the containerised infrastructure, the /g/data/xp65/public/apps/med_conda_scripts/analysis3-25.09.d/bin/activate file is the launcher script, which cannot be sourced and instead the command above throws the error:

/g/data/xp65/public/apps/med_conda_scripts/analysis3-25.09.d/bin/activate: line 30: <VSCode_chdir>/launcher_conf.sh: No such file or directory
FATAL: configuration disallows users from running sandbox containers

As a consequence, when an analysis3 kernel is selected in VSCode, it cannot also activate its environment and, as a consequence, it doesn't set the PROJ_DATA env variable (along with other potentially needed env variables).

Proposed solution

The proposed solution is to allow the launcher script to be sourced, and modify the launcher script logic so that, when sourced, it gets run in a subshell (not soured) and the actual containerised file is sourced within the singularity container (achieving a result similar to the second example in the Reason of the error section above).