Pip upgrade to 22.3 windows10

Did you run the command given in the message? python.exe -m pip install --upgrade pip.


yes. I’ve run it several times. I re-booted and now I get this error after trying to install pip:

C:\WINDOWS\system32>python -V
Python 3.9.7

C:\WINDOWS\system32>pip -V
pip 22.1.2 from C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip (python 3.9)

C:\WINDOWS\system32>python.exe -m pip install --upgrade pip
Requirement already satisfied: pip in c:\users\araki\appdata\roaming\python\python39\site-packages (22.1.2)
Collecting pip
  Downloading pip-22.3.1-py3-none-any.whl (2.1 MB)
     ---------------------------------------- 2.1/2.1 MB 6.9 MB/s eta 0:00:00
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 22.1.2
    Uninstalling pip-22.1.2:
      Successfully uninstalled pip-22.1.2
  WARNING: No metadata found in c:\users\araki\appdata\roaming\python\python39\site-packages
  Rolling back uninstall of pip
  Moving to c:\users\araki\appdata\roaming\python\python39\scripts\pip.exe
   from C:\Users\araki\AppData\Local\Temp\pip-uninstall-fq9ov9kf\pip.exe
  Moving to c:\users\araki\appdata\roaming\python\python39\scripts\pip3.10.exe
   from C:\Users\araki\AppData\Local\Temp\pip-uninstall-fq9ov9kf\pip3.10.exe
  Moving to c:\users\araki\appdata\roaming\python\python39\scripts\pip3.9.exe
   from C:\Users\araki\AppData\Local\Temp\pip-uninstall-fq9ov9kf\pip3.9.exe
  Moving to c:\users\araki\appdata\roaming\python\python39\scripts\pip3.exe
   from C:\Users\araki\AppData\Local\Temp\pip-uninstall-fq9ov9kf\pip3.exe
  Moving to c:\users\araki\appdata\roaming\python\python39\site-packages\pip-22.1.2.dist-info\
   from C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\~ip-22.1.2.dist-info
  Moving to c:\users\araki\appdata\roaming\python\python39\site-packages\pip\
   from C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\~ip
ERROR: Exception:
Traceback (most recent call last):
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\cli\base_command.py", line 167, in exc_logging_wrapper
    status = run_func(*args)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\cli\req_command.py", line 205, in wrapper
    return func(self, options, args)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\commands\install.py", line 407, in run
    installed = install_given_reqs(
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\req\__init__.py", line 73, in install_given_reqs
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\req\req_install.py", line 773, in install
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\operations\install\wheel.py", line 730, in install_wheel
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\operations\install\wheel.py", line 647, in _install_wheel
    generated_console_scripts = maker.make_multiple(scripts_to_generate)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_vendor\distlib\scripts.py", line 428, in make_multiple
    filenames.extend(self.make(specification, options))
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_internal\operations\install\wheel.py", line 428, in make
    return super().make(specification, options)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_vendor\distlib\scripts.py", line 417, in make
    self._make_script(entry, filenames, options=options)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_vendor\distlib\scripts.py", line 317, in _make_script
    self._write_script(scriptnames, shebang, script, filenames, ext)
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_vendor\distlib\scripts.py", line 247, in _write_script
    launcher = self._get_launcher('t')
  File "C:\Users\araki\AppData\Roaming\Python\Python39\site-packages\pip\_vendor\distlib\scripts.py", line 396, in _get_launcher
    raise ValueError(msg)
ValueError: Unable to find resource t64.exe in package pip._vendor.distlib

[notice] A new release of pip available: 22.1.2 -> 22.3
[notice] To update, run: python.exe -m pip install --upgrade pip


I opened python.exe and tried to run the install

>>> -m pip install --upgrade pip
  File "<stdin>", line 1
    -m pip install --upgrade pip
SyntaxError: invalid syntax

So, I’ve run the pip install from cmd as admin and now python.exe. none of them work.

You’ll most likely want to run the upgrade in a non-admin terminal


That command isn’t Python code but something to run in your terminal.

It’s interesting that pip is installed as a --user package in your profile’s roaming appdata. If you installed Python for all users, pip may have previously opted to do a --user install without getting your consent, which is quite rude. Personally, I never want that. If I mistakenly update an all-users installation of pip from a shell that lacks admin access, I immediately uninstall it via py [-X.Y] -m pip uninstall pip. Then I open an administrator shell and do a proper upgrade of the system installation of pip.


I’m going to uninstall anaconda and python and reinstall all this stuff.


If using Anaconda to install Python you shouldn’t be using pip to upgrade pip, you should be using conda to upgrade pip. You’ve likely broken your Anaconda and Python environment by trying to overwrite conda installed packages with pip.

For user troubleshooting problems with Anaconda (and for that matter Python) you are in the wrong forum.

For Anaconda installs you can go here: https://community.anaconda.cloud/

For vanilla Python installs (not installed using Anaconda) you can go here: Python Help - Discussions on Python.org or another place that tends to be very helpful is here: https://www.reddit.com/r/learnpython/

Pip deliberately defaults to a user install if the system location is not writeable. This is because when we used to fail in this case, users would try sudo, which would work but break their distro managed installation. After many years of problems, we settled on the current approach as a solution.

In this case, it looks like the OP installed python as admin (presumably an all users installation) but then tried to upgrade pip as a non-admin user.

In general, I’d recommend sticking with the default (a per-user install) when installing python on windows, unless you have a specific reason for needing an all-users install, and you are a sysadmin (so you have a good understanding of the permission issues involved).

I think it’s implemented badly. By default, pip should prompt for consent before switching to a --user install. If users don’t want to be prompted, there can be a setting to either always allow or never allow automatic --user installs. Personally, I never want it. When I have Python installed at the system level, that’s not by accident. The only accident is that I forgot to use a shell with admin access when upgrading, for which pip punishes me by making me uninstall an automatic --user install that I don’t want.

:person_shrugging: Feel free to raise an issue on pip proposing a better behaviour. I personally have no particular stake in the current behaviour, it was designed mainly to handle the concerns of Unix users and distro maintainers, where the ergonomics may be different. But any further discussion is probably off-topic for this thread.

Personally, when I’m on Linux, I’d especially prefer pip giving an error or prompting for confirmation to fall back to a user install, though for slightly different reasons as @eryksun on Windows. I almost always work in venvs, so if I forget to activate one, I’d rather pip fail or prompt than silently install into --user if I don’t deliberately sudo it; at least one time this happened, it resulted in a very laborious cleanup and reinstall effort.

Honestly, if it were up to me, now that pip has a solver and dry run support, I’d much rather it act like most package managers (either by default or at least with an option) and display what it is going to do (i.e. --dry-run, preferably in a more readable format) before doing it and asking for confirmation. That would have avoided the overwhelming majority of issues (on different platforms and on both *conda and Python.org) I’d ran into where an environment got screwed up due to either user error (installing in the wrong env, wrong interpreter, with/without sudo, the wrong spec, or some other issue) or packaging issues, and is the single biggest feature I miss vs. conda (and I typically run pip with --dry-run first for that reason, despite it taking twice the time and effort). But that’s getting a bit out of scope here…

1 Like

I have some real world experience of this causing issues, I managed an Anaconda distribution at a large enterprise and for technical and cultural reasons it made sense to make the base install of Anaconda read-only and users who wanted Python with other packages could use venv or conda to create their own environments.

The problem was that pip --user install is fundamentally at odds with conda environments, and would often break even the base environment. A user would pip install something, pip would default to user install because the base directory is read only, and then all of a sudden their Spyder installation would no longer work.

The solution was fairly easy though, we updated the default pip.ini we distributed with the Anaconda install to include a user=false flag (forget the specific config). And it was my opinion that because we controlled the environment and had specific needs it wasn’t worth bringing up or arguing it should be default. But thought people might be interested in a real world example.


I haven’t personally seen that too much, but our other developers have seen that happen, so we specifically mention it and how to fix it in some of our tutorial/help videos.

Also, just FYI, it is for reasons like this that we’ve been recommending our standalone installers to avoid the many issues with users doing all sorts of ill advised things like this and breaking Spyder. We also advising that if they do install Spyder with Anaconda, they use a separate isolated env instead of base. In addition to our stable pynsist and py2app based ones, we now have new experimental conda-based installers for all three major platforms, which will allow for auto-updating, installing Spyder plugins and creating/modifying user environments all in a controlled manner, combining the benefits of both a conda and a standalone install while opening the door to adding package, environment and plugin management functionality right within Spyder.

pip config set global.require-virtualenv true

See also


See also: It should be possible for a Python environment to disable the "user site" functionality without patching the stdlib · Issue #99312 · python/cpython · GitHub

I’ve been preventing accidental --user installs by making my ~/.local/lib/python3* read-only :sweat_smile:

1 Like

Thanks for the advise but this wasn’t really about Spyder, as Spyder breaking was a symptom of pip --user installs being fundamentally incompatible with using conda to manage your Python environments. It could have happened with any package installed with conda, Spyder was just more likely to break due to have more dependencies.

The problem is that you may only install packages via conda in one conda environment but in another conda environment you might be using conda to just bootstrap Python and use pip install to install everything else. If you use pip --user install in the latter environment those packages are still picked up by the former environment.

Anaconda was the main way that our users (which had a very wide range of technical backgrounds) got access to Python, and they weren’t allowed to install software manually, so some users were always going to use Spyder via Anaconda to do their work. So I tried hard to make the default behavior as safe as possible, although I never made the configs read only so if a user wanted to force break their own environment I wasn’t going to stop them.

Well to at least stop the automatic user behavior you can also do what I described in my previous post which if I remember rightly was set like this:

pip config set global.user false

Ok. I appreciate all the feedback from everyone.

If I uninstall anaconda, would this solve my problem? Or best to uinistall BOTH CONDA & VANILLA PYTHON?

Thanks for the help

It seems to me like the problems with --user have very little to do with conda specifically. It’s equally problematic, and should not be used, when you have multiple virtualenvs. I think --user came from a world where users would always have a single Python (system) install, and not multiple environments. Now that the latter is the recommend way of operating, and most users understand that, --user is more harmful than helpful. It should probably be disabled by default, with an understandable error message for users that run into permissions errors.

If you remove all your installs, the problem will go away. But that’s a pretty destructive action. Instead, I think the one thing you have to understand is where Python and Pip are coming from. If this is the Pip from a Conda environment, you should upgrade it with conda (so conda upgrade pip rather than python -m pip install --upgrade pip).