I interpreted what @rgommers meant with that was that regardless of environment type (conda or venv), the main problem with --user
by default is the same, making it easier to install things into the base Python installation when an environment is not properly activated (either due to user error or another issue). But perhaps he meant something different? I believe there might be an issue with --user
when using a pip-installed (i.e. unpatched) pip inside a conda environment, but that wasn’t what I took Ralf to be referring to there.
Also, to note, both system and user-installed packages will be ignored when a venv is activated so long as --system-site-packages
is not passed when creating the venv (and I would assume, and believe I saw before, but have not tested again to confirm, that the same is true of user packages when that option is passed in addition to system packages).
The ultimate problem likely didn’t have anything to do with permissions, but rather due to basic user errors and/or simple confusion (I cannot be sure specifically, since there wasn’t enough information provided about either your environment or what specifically you did).
To avoid problems in the future, I suggest first running, from your regular system command prompt (not Anaconda prompt):
python.exe -m pip install --upgrade pip
pip config set global.require-virtualenv true
This will ensure you don’t accidentally install things into your globally-installed Python directly.
Then, when using Python.org Python (i.e. from a non-Anaconda prompt), use venv
virtual environments to install your packages instead. This will ensure that if something goes wrong, you won’t need to reinstall Python, just recreate the environment, will avoid any permissions issues, and will ensure that you won’t accidentally install packages with pip either with or without Anaconda anywhere that your *conda Python could pick them up. Also, always use python -m pip install --upgrade pip
to upgrade pip itself in Python.org installed Python.
In general, when using any Python install:
- Never use
setup.py <anything>
oreasy_install <anything>
. These are long-obsolete, legacy install methods that are likely to break things. - Always triple-check that the venv/conda environment you expect is activated before installing anything. It should show in parenthesis in/around your command prompt and you can also use
where python
to determine the path to the currently activated Python environment. - Ensure the install is doing what you expect before committing to it, by looking at the
conda install
output or the output ofpip install --dry-run
. Are a bunch of packages being installed that you didn’t ask for, or you know are already installed, or at a different path than you expect? Does something else look off? This may be a little tough at first, but as you gain more experience, you’ll learn what to expect. - If you aren’t sure about something, before doing anything, ask someone you trust that is an experienced Python/Conda user to give it a second look. If you don’t have someone, find one
When using Conda (e.g. via Anaconda prompt):
-
Either download minforge instead of Miniconda (or Anaconda), or run the following to set your default channel to
conda-forge
, for a wider and more up to date package selection and avoiding having to mix channels or usepip
(which both cause a multitude of problems):conda config --add channels conda-forge conda config --set channel_priority strict
-
Never touch the base conda environment. Always create new conda environments and install specific packages you need in them, for the same reasons as pip (namely, if something goes wrong, just delete the env and recreate it, no need to reinstall, and it greatly decreases the chance of package conflicts and makes it easier to see what you have installed).
-
Avoid using
pip
to install anything in a Conda environment, always useconda
unless there are no conda-forge packages available. If you do usepip
, I suggest just creating a fresh environment withconda create -n pip-env python
, activating it and then installing everything withpip
from the get-go (except forpip
itself; always manage that withconda
). Especially avoid installing/upgradingpip
usingpip
itself in a conda environment.
While nominally aimed at Spyder users, our Don’t mix pip and conda video walks you through most of the latter steps and provides more guidance on fixing and avoiding these situations.