Every single command from pip runs super slow #8485
Comments
triage-new-issues
bot
added
the
S: needs triage
|
What are you referring by “it used to”? Does this slowdown happen because of a pip upgrade or a system upgrade? If it happens out of nowhere, it is very likely not a pip problem, but something happening on your particular machine, which pip does not have control over. |
|
No, I didn't do any pip upgrade. Windows 10 does make frequent updates but I cannot fathom how this impacts performance with pip inside WSL2. I'm hoping someone could point me a direction on how I can even trace this problem. Right now pip doesn't output any error messages so no way to know what's going on. |
|
Could you share how many packages are already installed (i.e. the output of [1] pkg_resources's WorkingSet construction on load, for those wondering what I'm talking about |
|
Same issue with me too. I ran |
This sounds plausible. WSL2’s filesystem performance is terrible if you access the Windows filesystem at the Linux side. What is the Python associated to your |
|
If we run same Sys path without pipenv environment activatedSys path with pipenv environment activatedIt could be possible if sys path is changed for global, then |
|
Hmm, none of the directories seem out of ordinary. Do you happen to mount any of the Windows directories? For example, do you symlink your home directory (or anything listed in I would probably try to temporarily move some of the entries listed in |
|
Edit: This may somehow be linked to the display? The slowdown largely goes away (takes 0.5 seconds) when I start up an X11 server (using MobaXterm). The reason I found this issue was that matplotlib was super slow so I tried to use pip to reinstall. I forgot that I needed to run an Xterm to use matplotlib. I have also encountered this problem and have the same output from my python's I'm developing a python package whose results need to be bench marked against a program that can only run in a unix environment. I use sublime test to edit the files in my windows directory and use the WSL2 to run the benchmark code on those files through the symlink. I can run the following commands without any slowdown: Running I tried the following without any success I'm not 100% what the best way of changing the Which I backup as follows So clearly there is something wrong with the paths. I'm not sure if this is relevant but I figured I'd mention it: Which still suffers the slowdown until the sys.path is set to an empty list and then reset back to the original list or this list. |
Maybe…? The entirely issue is very weird to me. If this is a |
|
Hello, my environment is: With My |
|
@MattiaFailla If you want a temporary fix I recommend running an X11 server such as MobaXterm(or some other equivalent). I don't understand why, but it did fix my slowdown issue for all commands. |
|
@ngraymon that’s odd but I will try this temp-fix. |
|
Just to confirm that the behavior is still the same I checked just now: Running |
|
@ngraymon Hello,
|
|
@MattiaFailla |
|
@ngraymon could you run python -m pip, and see if that is also slow? If it is, and you have a new-enough Python version, please provide us the output of |
pradyunsg
added
S: awaiting response
triage-new-issues
bot
removed
the
S: needs triage
|
@pradyunsg I ran I ran the following:
It appears the culprit for the Hopefully that is helpful :) |
Combined with the weird thing around having an X server helping, I wonder if keyring depends on a GUI, and there's some code in there that tries to find X and causes a delay until it concludes there isn't one? |
|
jaraco/keyring#434 seems related, but the advice there on disabling points to the docs which states what you've already tried. |
|
Experiencing this issue as well, believe it started after running a routine After removing this line from .bashrc and restarting WSL2, pip behaves as expected. Not quite sure if this points anyone in the right direction, as I'm not sure how to proceed from here. |
|
It appears as if I was able to permanently fix the issue by updating keyring with |
|
Wonderful, cjpellicci's suggestion of |
|
The above doesn't seem to work for me. There's no keyringrc.cfg in either ~/.local/share/python_keyring/ or ~/.config/share/python_keyring/. Could this be a different behaviour between WSL Ubuntu and Ubuntu? |
Yes: jaraco/keyring#403 |
Worked for me! Thanks |
|
This should be much better with keyring 21.5 or above. It's possible that the delay will occur when code tries to use keyring instead of at import, but it sounds like a lot of people are hitting this in cases where keyring is imported but never used, and those cases should be fixed. If you still see a ~25 second delay with an up to date keyring, please check a standalone Technical detailsKeyring tries at import to determine which of its backends to use. There are two main Linux backends: SecretStorage (nominally a standard, but mainly implemented by Gnome) and KWallet (KDE). Both are accessed through D-Bus, a local communication system. D-Bus supports 'service activation', i.e. starting a program when there is a request for it, and then passing it the request. These long waits occur when one of these services is installed but doesn't start correctly for some reason - D-Bus' default configuration allows a very long time for a service to start before it gives up and sends back an error. Keyring was making a request to each service as part of choosing which to use, so this wait could occur on import. Thanks to @siebenmann for helping to pin this down. The fix, for now, is to avoid making requests to the services during backend selection. Instead, keyring will just check if each service is available. This should never lead to a long wait. However, you may get a long wait instead if the code tries to get or set a password with keyring, because at that point it will make a request to the service, which may need to be activated. Keyring is still doing somewhat complex operations on import, which is not ideal. I'd hope that a future version can defer choosing a backend until a keyring function is called, so it has no surprising behaviour on import. |
|
And with keyring 21.6, keyring should initialise its backend lazily, so importing it should take no longer than any other similarly sized package. |
FYI, I included a patch in #9434 that makes the loading of |
@poday This also works for me, thanks a lot! I've now added to my bashrc: |
|
Hey guys, this might be pretty dumb, but I was struggling with this for a while and "sudo apt-get update", "sudo apt-get upgrade" fixed it for me. |
I was having the same problems, but I'm using X410. Before turning it on pip3 list was taking a very long time (couldn't wait for it to finish). When I turned on X410, it finished almost immediately when running it again. |
|
I even see request lib is also performing slow. I switched to linux because I was frustrated with windows updates but now I think windows 10 is much faster in executing web scraping. I think I will go back to windows 10. |
@heidemn-faro $ alias pip3='DISPLAY= pip3'
$ alias pip='DISPLAY= pip'
$ pip3 list #speeded-up
$ pip list #speeded-up
$ echo ${DISPLAY} #not changedEnvironment:
|
|
Any Way pip install --upgrade pip --index-url https://mirrors.sustech.edu.cn/pypi/simple |
|
@AyanUpadhaya That sounds like the issue I had (windows and linux) and was a problem with |
This file didn't exist on my machine, I just created it and it works. |
Pip install was very slow, and this solved it |
This seems to be the solution for me as well. To have the solution directly here in the issue, here is what I have in my |
|
Not sure if this was covered previously, but in my case pip started causing problems after I had scrapped my existing virtualenv for a repo and initiated a new one. At this stage it would take a whole minute before any pip command would even begin executing while i was working in my new virtualenv. Solution: |
|
I guess you can try to active xming or some like that. |
|
same issue: pip3 list 0.66s user 0.05s system 2% cpu 25.744 total my env and output of
|
|
I update keyring solve my problem |
|
This should not be an issue with the latest pip and the latest keyring. If you're still seeing this with the latest versions of pip and keyring, please file a new issue. :) |
Similar to this, I solved my issue by disabling IPv6 only on one interface. If you don't even use IPv6 you can easily deactivate it globally or only on your interface. TDLR: IPv6 resolution is preferred over IPv4 making installing a package painfully slow This solved my issues with Poetry and PIP being extremely slow to install packages. I've written a more extensive post on this workaround. Have a look if you want to get more information. |
and others
Environment
Description
Any commands on pip3 runs super slow including simple ones like:
pip3 list
It used to take 1~2 seconds and now it's like a minute.
Expected behavior
How to Reproduce
Tried to clean cache dir and it didn't work.
Tried to purge python3-pip package and reinstall and didn't work.
Not sure if it's linked to the recent Windows 10 19041 update.
The text was updated successfully, but these errors were encountered: