I am trying to install some packages upon newly created conda environment. But weirdly it is already full of packages, which have been used in other previous conda environments. For example, I noticed var conda environment already share the packages with other environments although I never asked to - I used conda create --name var -y python=3.10 command:
(base) XXX@XXX-XXX:/home/nas/XXX/B/C$ conda activate var
(var) XXX@XXX-XXX:/home/nas/XXX/B/C$ pip freeze
absl-py==2.1.0
av==14.2.0
certifi==2025.1.31
charset-normalizer==3.4.1
chumpy==0.70
cmake==3.31.6
contourpy==1.2.1
cycler==0.12.1
dearpygui==1.7.1
diff_gaussian_rasterization @ file:///home/nas/XXX/B/D/submodules/diff-gaussian-rasterization
...
, which means conda environments are not isolated and mixed to each other, therefore jointly affected whenever I update the package version in each environment.
One suspicious part is SafetyError: The package for libstdcxx-ng located at /home/nas/XXX/anaconda3/pkgs/libstdcxx-ng-11.2.0-h1234567_1 appears to be corrupted. The path 'lib/libstdc++.so.6.0.29' has an incorrect size.which is shown below of the following messages:
(base) XXX@XXX-XXX:/home/nas/XXX/B/C$ conda create --name var -y python=3.10
Collecting package metadata (current_repodata.json): done
Solving environment: done
==> WARNING: A newer version of conda exists. <==
current version: 22.9.0
latest version: 25.3.0
Please update conda by running
$ conda update -n base -c defaults conda
## Package Plan ##
environment location: /home/nas4/XXX/anaconda3/envs/var
added / updated specs:
- python=3.10
The following NEW packages will be INSTALLED:
_libgcc_mutex pkgs/main/linux-64::_libgcc_mutex-0.1-main None
_openmp_mutex pkgs/main/linux-64::_openmp_mutex-5.1-1_gnu None
bzip2 pkgs/main/linux-64::bzip2-1.0.8-h5eee18b_6 None
ca-certificates pkgs/main/linux-64::ca-certificates-2025.2.25-h06a4308_0 None
ld_impl_linux-64 pkgs/main/linux-64::ld_impl_linux-64-2.40-h12ee557_0 None
libffi pkgs/main/linux-64::libffi-3.4.4-h6a678d5_1 None
libgcc-ng pkgs/main/linux-64::libgcc-ng-11.2.0-h1234567_1 None
libgomp pkgs/main/linux-64::libgomp-11.2.0-h1234567_1 None
libstdcxx-ng pkgs/main/linux-64::libstdcxx-ng-11.2.0-h1234567_1 None
libuuid pkgs/main/linux-64::libuuid-1.41.5-h5eee18b_0 None
ncurses pkgs/main/linux-64::ncurses-6.4-h6a678d5_0 None
openssl pkgs/main/linux-64::openssl-3.0.16-h5eee18b_0 None
pip pkgs/main/linux-64::pip-25.0-py310h06a4308_0 None
python pkgs/main/linux-64::python-3.10.16-he870216_1 None
readline pkgs/main/linux-64::readline-8.2-h5eee18b_0 None
setuptools pkgs/main/linux-64::setuptools-75.8.0-py310h06a4308_0 None
sqlite pkgs/main/linux-64::sqlite-3.45.3-h5eee18b_0 None
tk pkgs/main/linux-64::tk-8.6.14-h39e8969_0 None
tzdata pkgs/main/noarch::tzdata-2025a-h04d1e81_0 None
wheel pkgs/main/linux-64::wheel-0.45.1-py310h06a4308_0 None
xz pkgs/main/linux-64::xz-5.6.4-h5eee18b_1 None
zlib pkgs/main/linux-64::zlib-1.2.13-h5eee18b_1 None
Preparing transaction: done
Verifying transaction: |
SafetyError: The package for libstdcxx-ng located at /home/nas/XXX/anaconda3/pkgs/libstdcxx-ng-11.2.0-h1234567_1
appears to be corrupted. The path 'lib/libstdc++.so.6.0.29'
has an incorrect size.
reported size: 17981480 bytes
actual size: 1594864 bytes
done
Executing transaction: done
#
# To activate this environment, use
#
# $ conda activate var
#
# To deactivate an active environment, use
#
# $ conda deactivate
I somewhat have a hint about the message since that file is affected by conda install -c "nvidia/label/cuda-11.7.1" cuda-toolkit ninja (which I used) as far as I know. Still I have no idea about whether it is related to my entangled environments problem and why it occurs.
How about in your Python session you try to make visible all environment variables relevant for your Python sessions by:
import os
for name, value in os.environ.items():
print("{0}: {1}".format(name, value))
first?
when I was working with HPC (high performance clusters), when Python was behaving strangely - like loading packages which I didn't install myself etc., I was looking for the PYTHONPATH environment variable. If that lists a lot of paths, then changing the order there or removing some of them made Python behave as I want.
In a similar way, listing all system and conda environment variables - could give you a hint.
# list conda environment variables
conda info
# list also system environment variables
conda info --system
E.g. look at the PATH variable:
Does your /home/nas/XXX/anaconda3/envs/var/bin is listed first?
=> if something else comes first, e.g. base/bin or /usr/bin/python => it would be the cause for the leaking.
==> put your conda env path first: execut export PATH=/home/nas/XXX/anaconda3/envs/var/bin:$PATH in your current shell and look, whether the problem still persists. You could also copy the entire content of echo $PATH's output, remove suspicious paths and set that
export PATH=the-modified-paths run in your current bash session - and then try - whether the problem is still there.
PYTHONPATH should be empty, except you set it => else this could be the reason for python packages already available.
==> unset by: unset PYTHONPATH
PYTHONUSERBASE unset or user-specific like ~/.local => packages from here would pollute a pip freeze
==> add export PYTHONNOUSERSITE=1 to your ~/.bashrc and source ~/.bashrc => this eliminates ~/.local's influence
CONDA_PREFIX should be your environment's base path /home/nas/XXX/anaconda3/envs/var
VIRTUAL_ENV (used by venv) should be empty - otherwise you are mixing venv and conda => bad!
LD_LIBRARY_PATH should be empty or only point to a lib inside var => otherwise your libstdc++ or CUDA is not looking only into your var
Obviously, you are using some HPC cluster computer with conda. Then it is very likely some environmental variable problem.
Look around in your system, whether something suspicious is set in
~/.bashrc and also whether there is some .condarc file where such variables are manipulated (probably at your home? ~/.condarc.