# Pip search is still broken **URL:** \ **Category:** Packaging\ **Created:** [September 1, 2022, 8:49pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680 "2022-09-01T20:49:04Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![nilamo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nilamo/32/8710_2.png) [@nilamo](https://discuss.python.org/u/nilamo)\ **Post date:** [September 1, 2022, 8:49pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/1 "2022-09-01T20:49:04Z")
…and the error says it’ll be deprecated in the future? That’s obviously bad, why is it just being turned off instead of fixed? The need to find packages who’s exact name you don’t know won’t go away, just because the ability to search for them has been taken away, lol. Is there any discussion about this anywhere? Is this a problem I can help fix? I find it extremely hard to believe that doing a full text search is an impossible task. Furthermore, the error says to check [https://status.python.org](https://status.python.org) for more info… but pip and/or package searching is nowhere on the status page, and there’s no indication at all that anything is other than 100% operational. Which is also extremely bad. ---
**Author:** ![ketozhang](https://avatars.discourse-cdn.com/v4/letter/k/8797f3/32.png) [@ketozhang](https://discuss.python.org/u/ketozhang)\ **Post date:** [September 1, 2022, 9:03pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/3 "2022-09-01T21:03:02Z")
Turning the question around, what can’t you get by using a internet search engine that you can with pip search? ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 1, 2022, 9:11pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/4 "2022-09-01T21:11:08Z")
The PyPI search API was disabled in late 2020. [This article](https://www.theregister.com/2021/05/25/pypi_search_error/) gives some background. I’m surprised you’ve only just noticed… `pip search` was built on the PyPI XML-RPC search API, so it no longer works because that API has been disabled. We should probably just remove the `pip search` command, to save confusion. ---
**Author:** ![nilamo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nilamo/32/8710_2.png) [@nilamo](https://discuss.python.org/u/nilamo)\ **Post date:** [September 1, 2022, 9:12pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/5 "2022-09-01T21:12:06Z")
Because if I’m trying to install something, and `apt search` doesn’t have any results, the next step is naturally to check `pip search`. But that doesn’t work, which is annoying. So I check [https://python.org](https://python.org), but there’s no search. There is at least a link to pypy from [python.org](http://python.org), but if you don’t know that pip is pulling from pypy, that link is not helpful. ---
**Author:** ![nilamo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nilamo/32/8710_2.png) [@nilamo](https://discuss.python.org/u/nilamo)\ **Post date:** [September 1, 2022, 9:13pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/6 "2022-09-01T21:13:30Z")
I didn’t just notice. I did however realize that it’s still not functional, and still hasn’t been fixed. If the xml-rpc api is no longer available, why not… use… a different api…? Obviously searching packages is working directly from [pypy.org](http://pypy.org), why can’t pip use the same functionality? ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 1, 2022, 9:27pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/7 "2022-09-01T21:27:32Z")
> [@nilamo](#): > > why not… use… a different api There is no such API. > [@nilamo](#): > > why can’t pip use the same functionality? Because PyPI (Warehouse) doesn’t expose it for 3rd party use. Which is almost certainly because the last time they did, it got abused to the point where it was causing service issues. I’ve updated the issue on the pip tracker [here](https://github.com/pypa/pip/issues/5216#issuecomment-1234795031) to propose that we finally deprecate and remove `pip search`, so that we no longer mislead people like yourself who think that it might work… (Please understand “why not just fix it” is _not_ a helpful comment, and will not be received positively - we _have_ considered the options and there really is no viable way to just make `pip search` start working again). I appreciate your frustration here, but honestly, you should just go to the PyPI website and use the search box there. It may not be ideal for your workflow, but it _works_, which is more than can be said for blaming the pip or PyPI maintainers… ---
**Author:** ![nilamo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nilamo/32/8710_2.png) [@nilamo](https://discuss.python.org/u/nilamo)\ **Post date:** [September 1, 2022, 9:35pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/8 "2022-09-01T21:35:24Z")
> [@pf\_moore](#): > > which is more than can be said for blaming the pip or PyPI maintainers… I didn’t realize I was giving the impression that I was blaming someone. I did, in fact, ask if there was some way I could help. Is there a way to mark this thread as solved? ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 1, 2022, 9:43pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/9 "2022-09-01T21:43:40Z")
Not a problem, it’s just that a lot of people over time have asked “why not just…” in one form or another, which gets a bit wearying. My comment was more in the form of a pre-emptive strike against anyone who reads this thread, then goes to the linked issue and starts complaining. That’s one reason I think we should probably just remove `pip search` at this point. No need to mark the thread as solved, if we just leave it here it’ll be fine. ---
**Author:** ![gst](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gst/32/352_2.png) [@gst](https://discuss.python.org/u/gst)\ **Post date:** [September 2, 2022, 5:39pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/10 "2022-09-02T17:39:19Z")
why not just give a better “human friendly” error message to pip search (instead of "command unknow or soon deprecated (or the current XMLRPC code -32500 error that’s given) ? ```auto $ pip search foobar error: pip has not(anymore) a search feature. You can check/search for your foobar: + here + or eventually here blabla ``` ? ---
**Author:** ![saaketp](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/saaketp/32/6703_2.png) [@saaketp](https://discuss.python.org/u/saaketp)\ **Post date:** [September 2, 2022, 7:00pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/11 "2022-09-02T19:00:55Z")
That’s what was suggested in the pip issue as well [https://github.com/pypa/pip/issues/5216#issuecomment-1235329876](https://github.com/pypa/pip/issues/5216#issuecomment-1235329876) and there is a PR to rephrase it [Rephrase the search XMLRPC disable error by pradyunsg · Pull Request #12173 · pypi/warehouse · GitHub](https://github.com/pypi/warehouse/pull/12173) ---
**Author:** ![mwichmann](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mwichmann/32/1364_2.png) [@mwichmann](https://discuss.python.org/u/mwichmann)\ **Post date:** [September 2, 2022, 10:45pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/12 "2022-09-02T22:45:12Z")
I realize I’m not adding anything helpful here, but it will absolutely be a surprise for newcomers with any kind of experience with other ecosystems that virtually all familiar “package managers” have some solution for searching via a command line interface, and Python does not. Consider apt/yum/dnf/zypper/pacman/(others-I-left-out) for Linux environments, `choco search` for Windows users interested in Chocolatey, plus `gosearch`, `npm search`, `gem search`, `ppm search` and… ---
**Author:** ![TagWolf](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tagwolf/32/9339_2.png) [@TagWolf](https://discuss.python.org/u/TagWolf)\ **Post date:** [October 15, 2022, 4:05am UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/13 "2022-10-15T04:05:55Z")
Please see some viable solutions below from a cybersecurity engineer with decades of experience such as one or more of the following: Fastest Solution: - Add a limiter on the server side to only allow X searches (especially larger ones) within X minutes and then lock out that specific IP for whatever time period is required to keep servers healthy. This can be done quickly and with no client updating and server side solutions only such as apache modules and iptables firewall rules. Longer Term Solutions: - Change the default behavior of pip to cache search results by default and only grab new package lists every 24 hours unless overridden - By default, limit searches to X rate unless a user has some other identifier (such as an api key / login) so abusive clients can be disabled ---
**Author:** ![mwichmann](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mwichmann/32/1364_2.png) [@mwichmann](https://discuss.python.org/u/mwichmann)\ **Post date:** [October 17, 2022, 6:00pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/14 "2022-10-17T18:00:33Z")
Local caching is the approach of well-known Linux distribution package managers (dnf, apt, pacman, etc.). Don’t know if there are reasons why that is less viable in the Python world - possibly a lesser acceptance of great globs of data being stored locally? ---
**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\ **Post date:** [October 17, 2022, 6:48pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/15 "2022-10-17T18:48:30Z")
My Debian/Sid workstation has over 200MiB of LZ4-compressed package metadata. The current package count in Sid is around 165K entries. Depending on what you want to search on PyPI, at best its project count is more than double that right now, and the count of releases/files pip has to take into account is one or two orders of magnitude higher. Granted, the type and volume of metadata used by apt and pip are not the same, but it should be fairly apparent that there is a significant difference in package quantity and churn between a (very large) Linux distro and PyPI. ---
**Author:** ![mwichmann](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mwichmann/32/1364_2.png) [@mwichmann](https://discuss.python.org/u/mwichmann)\ **Post date:** [October 17, 2022, 7:14pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/16 "2022-10-17T19:14:55Z")
Perhaps an opt-in mechanism would be more appealing - for the Debian world analogy, think `apt-file`, which is not default, and has to have the database populated by request, but then does provide for a number of very useful queries, ---
**Author:** ![domdfcoding](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/domdfcoding/32/2544_2.png) [@domdfcoding](https://discuss.python.org/u/domdfcoding)\ **Post date:** [October 20, 2022, 2:18pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/17 "2022-10-20T14:18:44Z")
The local caching approach was my motivation for [GitHub - domdfcoding/pypi\_search: Metadata for a client-side search of PyPI](https://github.com/domdfcoding/pypi_search), which is updated every 30 minutes with new releases’ names and summaries. The tool is modelled after apt-cache, which only searches (the debian equivalent of) that metadata. The total size is about 35MB, but since it’s a git repository you only have to download the delta each time you refresh your local version. ---
**Author:** ![gargolito](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gargolito/32/9405_2.png) [@gargolito](https://discuss.python.org/u/gargolito)\ **Post date:** [October 21, 2022, 1:56pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/18 "2022-10-21T13:56:18Z")
I wrote this a while back when it was first turned off. I was just learning python at the time so the code is fugly but it works. [GitHub - gargolito/search-pypi: search pypi.org](https://github.com/gargolito/search-pypi) ---
**Author:** ![itsdotscience](https://avatars.discourse-cdn.com/v4/letter/i/ecccb3/32.png) [@itsdotscience](https://discuss.python.org/u/itsdotscience)\ **Post date:** [December 22, 2022, 8:33am UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/19 "2022-12-22T08:33:39Z")
Or, while not the greatest but brings basic capability back pip install pip\_search (note that \_ ) then pip\_search and for some cheap integration for \*sh ```auto alias pip='function _pip(){ if [$1 = "search"]; then pip_search "$2"; else pip "$@"; fi; };_pip' ``` and the windows folks (oh yeah, blast from the past here hah…i had to look up the if syntax, its been…longer than i care to admit knowing this lol) `doskey pip= IF $1 == search ( pip_search $2 $3 $4 $5 $6 $7 $8 $9 ) ELSE ( pip $* )` (quick edit to fix additional parameters if passed) The only things above I can take credit for are knowing about “pip\_search” and seeing the lack of windows equiv. alias for cmd.exe that doskey bit. 🙂 reference: > **[pip-search](https://pypi.org/project/pip-search/)** > > A package to search like pip used to, via PyPi ---
**Author:** ![eryksun](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/eryksun/32/697_2.png) [@eryksun](https://discuss.python.org/u/eryksun)\ **Post date:** [December 22, 2022, 12:01pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/20 "2022-12-22T12:01:10Z")
> [@itsdotscience](#): > > and the windows folks (oh yeah, blast from the past here hah…i had to look up the if syntax, its been…longer than i care to admit knowing this lol) > > `doskey pip= IF $1 == search ( pip_search $2-* ) ELSE ( pip $* )` Of course it’s not MS-DOS DOSKEY blasting in from the 1980s. It’s [“doskey.exe”](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/doskey) for the Windows NT console, blasting in from the 1990s. Each application that’s attached to a console session has a command history buffer, plus a set of input aliases that match at the beginning of an entered line of text. Attached applications (e.g. “cmd.exe” or “python.exe”) have nothing to do with this. For example, when an application calls `ReadConsoleW()`, the console host has already applied any matching alias such as “pip”. “doskey.exe” provides command-line access to the command history and input alias functions in the console API. The API for input aliases is documented: - [`AddConsoleAliasW`](https://learn.microsoft.com/en-us/windows/console/addconsolealias) - [`GetConsoleAliasesLengthW`](https://learn.microsoft.com/en-us/windows/console/getconsolealiaseslength) - [`GetConsoleAliasesW`](https://learn.microsoft.com/en-us/windows/console/getconsolealiases) - [`GetConsoleAliasExesLengthW`](https://learn.microsoft.com/en-us/windows/console/getconsolealiasexeslength) - [`GetConsoleAliasExesW`](https://learn.microsoft.com/en-us/windows/console/getconsolealiasexes) But most of the command history API is undocumented: - [`SetConsoleHistoryInfo`](https://learn.microsoft.com/en-us/windows/console/setconsolehistoryinfo) - [`GetConsoleHistoryInfo`](https://learn.microsoft.com/en-us/windows/console/getconsolehistoryinfo) - `SetConsoleNumberOfCommandsW` - `GetConsoleCommandHistoryLengthW` - `GetConsoleCommandHistoryW` - `ExpungeConsoleCommandHistoryW` ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [December 27, 2022, 3:48pm UTC](https://discuss.python.org/t/pip-search-is-still-broken/18680/21 "2022-12-27T15:48:37Z")
At this point, the message that `pip search` provides is: ```auto ❯ pip search random-text-here ERROR: XMLRPC request failed [code: -32500] RuntimeError: PyPI no longer supports 'pip search' (or XML-RPC search). Please use https://pypi.org/search (via a browser) instead. See https://warehouse.pypa.io/api-reference/xml-rpc.html#deprecated-methods for more information. ``` That should resolve most of the concerns raised in OP, and clearly explains what does not work. > > > Based on the idea from https://github.com/pypa/pip/issues/5216#issuecomment-1235…329876.