make python user site-packages isolation in .local directory configurable

[kalefranz]

As described in #7671 (comment)

For activated non-base conda environments, conda activate will actually go ahead and set the PYTHONNOUSERSITE environment variable, I'm suggesting you do now yourself. By default it will not set it for the base environment, whether the base environment is properly activated or not. This behavior will all be configurable, and there appear to be three states to what we're proposing for python interpreter isolation from ~/.local: disabled, non-base, all. The default value for the configuration, as proposed, would be the non-base one.

xref: #448
xref: #7173

[maphew]

Where do I set PYTHONNOUSERSITE=True in a way that leaves it off for default system shells, on for Conda, and won't be clobbered by upgrades?

[cooijmanstim]

@maphew This seems to work for me:

~/miniconda3/envs/py3/etc/conda $ cat activate.d/pythonnousersite.sh 
export CONDA_PYTHONNOUSERSITE_BACKUP=$PYTHONNOUSERSITE
export PYTHONNOUSERSITE=1
~/miniconda3/envs/py3/etc/conda $ cat deactivate.d/pythonnousersite.sh 
export PYTHONNOUSERSITE=$CONDA_PYTHONNOUSERSITE_BACKUP

[nehaljwani]

What's the rationale behind not setting it for the base environment as well?

[kalefranz]

I would vote that it should be, but somebody somewhere in one of these linked issues objected to that.

[zack-kimble]

For activated non-base conda environments, conda activate will actually go ahead and set the PYTHONNOUSERSITE environment variable, I'm suggesting you do now yourself. By default it will not set it for the base environment, whether the base environment is properly activated or not. This behavior will all be configurable, and there appear to be three states to what we're proposing for python interpreter isolation from ~/.local: disabled, non-base, all. The default value for the configuration, as proposed, would be the non-base one.

Is this something planned for 4.6?

I would vote for "all" being the default. I understand there are use cases where users want conda base (or other environments) to read from ./local, but aren't these anti-patterns? Shouldn't defaults fit the suggested use of conda as an environment+package+dependency manager?

[fgp]

I wonder if the right way to fix this wouldn't be a package the adds an activation scripts to etc/conda/activate.d. In most of my conda environments, I currently have a script etc/conda/activate.d/no-userdirs.sh that contains

export PYTHONNOUSERSITE=1
export R_LIBS_USER="-"

which takes care of the issue for both R and python. The nice thing about a package would be that it can handle any interpreter that has similar issues and whose search path is configurable with environment variables -- why I guess is that case for all serious scripting languages.

If there is interest in this, I could create and submit a package (a proper package would of course take care of undoing the change during conda deactivate)

[msarahan]

@fgp that sounds like a really good way to do it. I recommend submitting your package to conda-forge. Are you familiar with that process?

[fgp]

Are you familiar with that process?

I think I once submitted a wrapper package for some CRAN package that one of my Bioconda packages depends on, so I'd sage vaguely familiar.

I guess I'm not exactly sure what the easiest way to create a package that just creates a single file is - but probably I can include the file in the feedstock repo, and the "build script" would just copy it?

Does anyone have a good suggestion for a package name? Maybe "ignore-user-directories"?

[mingwandroid]

I prefer conda-ecosystem-user-package-isolation

[fgp]

Here is a pull request for a package such as I proposed conda-forge/staged-recipes#7965

I still need to test the actual package, but it principle it should work.

[RafalSkolasinski]

Sorry guys for a dummy question, but it is hard to find out what is actually going on with site-package isolation -> lots of contradicting posts, issues, stackoverflow questions...

Is now the preferable way to isolate from site-packages by installing

conda install -c conda-forge conda-ecosystem-user-package-isolation      

?

Wouldn't it be better to include that by default in conda and enable/disable with some .condarc option?

[fgp]

You can make conda install the isolation package into each new environment you create by default by setting create_default_packages to conda-ecosystem-user-package-isolation.

Having a second option that amounts to the same thing might make it more obvious to new users how to do this, but feels a bit redundant. I can see the merit of both arguments, what do others say?

[RafalSkolasinski]

You can make conda install the isolation package into each new environment you create by default by setting create_default_packages to conda-ecosystem-user-package-isolation.

I will give it a shot and come back here if it won't work for some reason.
Good enough for me if I can get this as default behaviour but config option is IMO cleaner.

Thanks!

[Ceciliogq]

Sorry guys for a dummy question, but it is hard to find out what is actually going on with site-package isolation -> lots of contradicting posts, issues, stackoverflow questions...

Is now the preferable way to isolate from site-packages by installing

conda install -c conda-forge conda-ecosystem-user-package-isolation      

?

Wouldn't it be better to include that by default in conda and enable/disable with some .condarc option?

I also see the .condarc option more elegant and cleaner. Has there been any progress on this @kalefranz? How could I set export PYTHONNOUSERSITE=True for all my conda envs using .condarc?

[sscherfke]

#394 is now closed and locked, but the issue still persists. Loading the user-site-packages is very troublesome for normal users.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   - What OS and version you reproduced the issue on
   - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!