PR: Do not check for updates if Spyder is in a system or managed environment

[mrclary]

Description of Changes

Check that sys.executable is not in /usr/bin or /usr/local/bin

Issue(s) Resolved

Fixes #22407

[ccordoba12]

Thanks for addressing this @mrclary!

[mrclary]

According to doc page:

1. Is it running outside of a virtual environment? It can determine this by whether sys.prefix == sys.base_prefix.
2. Is there an EXTERNALLY-MANAGED file in the directory identified by sysconfig.get_path("stdlib", sysconfig.get_default_scheme())?

On my machine, I have the following observations.

• sys.prefix == sys.base_prefix evaluates True for the system Python (/usr/bin/python3), conda environments, and pyenv environments. It evaluates False for virtual environments created with python -m venv.
• There is no EXTERNALLY-MANAGED file in the directory identified by sysconfig.get_path("stdlib", sysconfig.get_default_scheme()) for pyenv (didn't expect there to be) nor for the system. For my system, Python=3.9.6, sysconfig.get_default_scheme does not exist, but sysconfig.get_path("stdlib") works just the same for both 3.9 and 3.10.

So, I think we should do the following checks:

• sys.executable.startswith(('/usr/bin/', '/usr/local/bin/'))
• os.path.exists(os.path.join(sysconfig.get_path('stdlib'), 'EXTERNALLY-MANAGED'))

If either are true, then do not check for updates.

But we need to exclude conda envs from this check, otherwise we won't be able to update Spyder in them.

We should not have to worry about this with the above checks.

[ccordoba12]

We should not have to worry about this with the above checks.

The problem is that EXTERNALLY-MANAGED can be added at some point to conda envs. The presence of that file prevents pip from managing packages for the corresponding env or installation, which applies to conda envs because they're managed by conda/mamba/micromamba.

[mrclary]

The problem is that EXTERNALLY-MANAGED can be added at some point to conda envs. The presence of that file prevents pip from managing packages for the corresponding env or installation, which applies to conda envs because they're managed by conda/mamba/micromamba.

I still don't quite understand. If EXTERNALLY-MANAGED is added to a conda environment, then neither pip nor conda will be able to modify the environment, correct?
If this is the case, then we would not be able to update the environment, so we should exclude it from checking for updates.
If this is not the case, i.e. pip cannot modify the environment but conda can modify the environment, we could update the environment, but I think we should still respect the intent of the EXTERNALLY-MANAGED file and not update.

[ccordoba12]

I still don't quite understand. If EXTERNALLY-MANAGED is added to a conda environment, then neither pip nor conda will be able to modify the environment, correct?

Nop, only pip won't be able to change the env and that's because conda is managing it.

If this is not the case, i.e. pip cannot modify the environment but conda can modify the environment, we could update the environment, but I think we should still respect the intent of the EXTERNALLY-MANAGED file and not update.

EXTERNALLY-MANAGED was created for pip (not for conda) so that it doesn't touch envs that are managed by a different package manager (not only conda, but brew, apt, dnf, etc). Furthermore, if that file is added by default to conda envs in the future, then we wouldn't be able to update our own installers.

[mrclary]

Nop, only pip won't be able to change the env and that's because conda is managing it.

Okay, so then pip install ... would fail in a conda environment if EXTERNALLY-MANAGED is present, and the appropriate interpretation is that the environment allows conda to manage but not pip.

[ccordoba12]

Okay, so then pip install ... would fail in a conda environment if EXTERNALLY-MANAGED is present, and the appropriate interpretation is that the environment allows conda to manage but not pip.

Exactly.

[ccordoba12]

One last comment, then this should be ready.

Also, you need to rebase on top of master so that this PR runs our new Remote client tests.

[ccordoba12]

Shouldn't we use is_conda_env here? You can import it from Spyder-kernels.

[mrclary]

That's a good question.

We use is_anaconda throughout Spyder's source code and it does essentially the same thing, so it does duplicate code, which is not ideal. I would suggest that we use is_conda_env from spyder-kernels exclusively and remove is_anaconda from the Spyder source code. Is there a compelling reason to keep is_anaconda?

[mrclary]

To be clear, I recommend removing is_anaconda in a separate PR

[ccordoba12]

I would suggest that we use is_conda_env from spyder-kernels exclusively and remove is_anaconda from the Spyder source code. Is there a compelling reason to keep is_anaconda?

is_anaconda came first and it's a simpler check because it doesn't depend on an interpreter. But I agree, we could remove it and leave is_conda_env instead, to make things simpler.

To be clear, I recommend removing is_anaconda in a separate PR

Ok, I think that's a good idea.

---

On a second thought, I think this is the right check in this case because we need to run it only for Spyder's interpreter. So, sorry for the noise.

[ccordoba12]

Thanks @mrclary!

[ccordoba12]

@meeseeksdev please backport to 6.x