Question: 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.

Answer: 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. Check for dot files' existence and their contents 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.