Disable user site-packages during de[activation]

[jjhelmus]

Description

Disable the user site-packages directory when retrieving the shell code for activation, deactivation and reactivation from CONDA_EXE. The output from these calls are evaluated by the shell and any extraneous output introduced by the user site-packages directory, such as by usercustomize.py or .pth files, will be evaluated.

An alternative would be to use Python in isolated mode (-I) to run the CONDA_EXE script. This would also ignore the PYTHON* environment variables and unsafe paths.

Note that this only adds this to Unix style shells. Windows specific shells (cmd, powershell) may still access the user site-packages directory during activation.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

closes #12444

[jezdez]

@jjhelmus Would you mind opening an issue please? We're trying to get away from PRs without prior record-keeping of what is being solved.

[jjhelmus]

@jjhelmus Would you mind opening an issue please? We're trying to get away from PRs without prior record-keeping of what is being solved.

Reported the issue in #12444

[jjhelmus]

The failing test is a result of conda being re-installed from defaults during the setup in the associated job:

The following packages will be SUPERSEDED by a higher-priority channel:

  anaconda-client    conda-forge/noarch::anaconda-client-1~ --> pkgs/main/linux-64::anaconda-client-1.11.0-py310h06a4308_0 
  beautifulsoup4     conda-forge/noarch::beautifulsoup4-4.~ --> pkgs/main/linux-64::beautifulsoup4-4.11.1-py310h06a4308_0 
  certifi            conda-forge/noarch::certifi-2022.12.7~ --> pkgs/main/linux-64::certifi-2022.12.7-py310h06a4308_0 
  chardet            conda-forge::chardet-5.1.0-py310hff52~ --> pkgs/main::chardet-4.0.0-py310h06a4308_1003 
  conda              conda-forge::conda-23.1.0-py310hff520~ --> pkgs/main::conda-23.1.0-py310h06a4308_0

This occurs in all the Linux conda-forge jobs.

Essentially these jobs are testing if the tests in this repo pass with the latest defaults conda package.

This test behavior should be fixed so that the development version of conda is tested with conda-forge packages but is outside the scope of this PR.

[jezdez]

BTW curious that chardet is older in main :-/

[travishathaway]

@jezdez, are we still trying to get this in for the upcoming release? The tests look like they are passing (there's just a single random error).

[jezdez]

@jezdez, are we still trying to get this in for the upcoming release? The tests look like they are passing (there's just a single random error).

Yeah, I think so, even though I'm not excited that this doesn't fix the Windows activation :-/

[jezdez]

pre-commit.ci autofix

[kenodegard]

the test as written passes on Windows without these changes so thats a false positive that should be removed

[github-actions]

Hi there, thank you for your contribution!

This pull request 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 pull request to remain open please:

1. Rebase and verify the changes still work
2. Leave a comment with the current status

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

Thanks!