从 https://status.python.org/ 公告的时间看,pip search
不能用已经十多天了:
Update - The XMLRPC Search endpoint is still disabled due to ongoing request volume. As of this update, there has been no reduction in inbound traffic to the endpoint from abusive IPs and we are unable to re-enable the endpoint, as it would immediately cause PyPI service to degrade again. We are working with the abuse contact at the owner of the IPs and trying to make contact with the maintainers of whatever tool is flooding us via other channels.
现在随便搜索一个包:
⋊> pip search <package>
ERROR: Exception:
Traceback (most recent call last):
File "~/.pyenv/versions/3.6.5/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 224, in _main
status = self.run(options, args)
File "~/.pyenv/versions/3.6.5/lib/python3.6/site-packages/pip/_internal/commands/search.py", line 62, in run
pypi_hits = self.search(query, options)
File "~/.pyenv/versions/3.6.5/lib/python3.6/site-packages/pip/_internal/commands/search.py", line 82, in search
hits = pypi.search({'name': query, 'summary': query}, 'or')
File "~/.pyenv/versions/3.6.5/lib/python3.6/xmlrpc/client.py", line 1112, in __call__
return self.__send(self.__name, args)
File "~/.pyenv/versions/3.6.5/lib/python3.6/xmlrpc/client.py", line 1452, in __request
verbose=self.__verbose
File "~/.pyenv/versions/3.6.5/lib/python3.6/site-packages/pip/_internal/network/xmlrpc.py", line 46, in request
return self.parse_response(response.raw)
File "~/.pyenv/versions/3.6.5/lib/python3.6/xmlrpc/client.py", line 1342, in parse_response
return u.close()
File "~/.pyenv/versions/3.6.5/lib/python3.6/xmlrpc/client.py", line 656, in close
raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -32500: "RuntimeError: PyPI's XMLRPC API has been temporarily disabled due to unmanageable load and will be deprecated in the near future. See https://status.python.org/ for more information.">
好在 pip install
没问题,可以安装一个 pip_search
暂时代替搜索。
谢谢楼主,都没注意到这个问题…
pip_search看来不错
pip search 现在都还用不了。看来只能用 pip-search
,再在 .zshrc
中加个 alias。
alias pip='function _pip(){
if [ $1 = "search" ]; then
pip_search "$2";
else pip "$@";
fi;
};_pip'
opened 02:03PM - 13 Apr 18 UTC
C: search
type: maintenance
state: awaiting PR
type: deprecation
As of today (Oct 7, 2022), `pip search` does not return results with PyPI (pypi.… org). Please use [pypi.org/search](https://pypi.org/search/) instead.
Relevant context on this that GitHub hides by default:
https://github.com/pypa/pip/issues/5216#issuecomment-746717561
> PyPI is shutting down the API that pip search used, because the design of that API was such that it made it easy for people to overwhelm and take down PyPI as a whole using that API. The pip search command doesn't work without that API, and we don't have a way to restore 1:1 functionality without it.
https://github.com/pypa/pip/issues/5216#issuecomment-744658558
> Here's the inevitable truth. The XMLRPC based search API either needs major surgery to somehow move the load off of the PyPI backends so we can just ignore if it breaks, massive clusters need to stop hammering it, or we need to deprecate it. [snip graph + few sentences] The fact that we've managed to keep it working to this point is frankly something that should provide us an immense amount of pride in engineering and shame in foresight.
[The status.python.org incident that (eventually) led to the XMLPRC `search` (which powers `pip search`) being disabled on pypi.org](https://status.python.org/incidents/grk0k7sz6zkp)
---
(original description below)
Currently pip allows you to search a repository by running ``pip search``, which will then print out a bunch of packages that match, see for example:
```
$ pip search requests
negotiator-3k (1.0.0) - Proper Content Negotiation for Python
The Negotiator is a library for decision making over Content Negotiation requests.
It takes the standard HTTP Accept headers (Accept, Accept-Language, Accept-Charset,
Accept-Encoding) and rationalises them against the parameters acceptable by the
server; it then makes a recommendation as to the appropriate response format.
This version of the Negotiator also supports the SWORDv2 extensions to HTTP Accept
in the form of Accept-Packaging.
odoo10-addon-sql-request-abstract (10.0.1.0.0.99.dev1) - Abstract Model to manage SQL Requests
odoo9-addon-sql-request-abstract (9.0.1.0.0.99.dev6) - Abstract Model to manage SQL Requests
odoo8-addon-sql-request-abstract (8.0.1.0.0.99.dev7) - Abstract Model to manage SQL Requests
zenodo-accessrequests (1.0.0a2) - Zenodo module for providing access request feature.
requests-wsgi-adapter (0.4.0) - WSGI Transport Adapter for Requests
requests-celery-adapters (2.0.9) - Requests lib adapters to send Celery messages (tasks)
odoo9-addon-hr-holiday-notify-employee-manager (9.0.1.0.0.99.dev1) - Notify employee's manager by mail on Leave Requests creation.
odoo9-addon-purchase-request-operating-unit (9.0.1.0.0) - Operating Unit in Purchase Requests
odoo10-addon-hr-holidays-notify-employee-manager (10.0.1.0.0.99.dev4) - Notify employee's manager by mail on Leave Requests creation.
odoo9-addon-sql-export (9.0.1.0.0.99.dev12) - Export data in csv file with SQL requests
odoo8-addon-sql-export (8.0.1.0.0.99.dev9) - Export data in csv file with SQL requests
...
```
The output here goes on for ~900 lines and the results are just complete trash. This is a better on Warehouse:
```
$ pip search --index https://pypi.org/pypi requests
requests (2.18.4) - Python HTTP for Humans.
INSTALLED: 2.18.4 (latest)
aiohttp-requests (0.1.0) - A thin wrapper for aiohttp client with Requests simplicity
anonymous-requests (0.2) -
apiclient-requests (0.1.2) - A simple python base package for building good api clients on
careful-requests (0.1.4) - Requests for header-sensitive servers (like Accept-Encoding)
crawl-requests (2.2.8) - crawl_requests(like requests) can update ua and proxy automatically.
gcloud-requests (1.1.9) - Thread-safe client functionality for gcloud-python via requests.
jsonapi-requests (0.6.0) - Python client implementation for json api. http://jsonapi.org/
jsonrpc-requests (0.4.0) - A JSON-RPC client library, backed by requests
nav-requests (1.1.4) - Renamed to `nav`
parse-requests (1.0.7) - parse-rest-python - A fast and simple Python library to interact with Parse.com REST API
play-requests (0.0.3) - pytest-play plugin driving the famous Python requests library for making HTTP calls
PyGithub-requests (1.26.0) - Use the full Github API v3
Randomized-Requests (1.0.2) - Python package that makes post and get request with random proxy and user agent
requests-aeaweb (0.0.1) - Requests wrapper to log onto AEAweb.org.
requests-aliyun (0.3.1) - authentication for aliyun service
requests-auth (1.0.2) - Easy Authentication for Requests
requests-aws (0.1.8) - AWS authentication for Amazon S3 for the python requests module
requests-aws4auth (0.9) - AWS4 authentication for Requests
requests-bce (0.0.5) - authentication for bce service
...
```
Which gives us ~111 lines of output, and which actually returns some meaningful output.
I believe that this command is a fairly regular source of confusion for users, primarily because it uses a different source of truth than ``pip install`` does, which means they need to configure the location to search at differently than they need to configure the location to install from (and the search API is not standardized, and to the best of my knowledge, very few alternative implementations support it.
There has been a long standing idea of switching search to use the ``PackageFinder()`` class to try and resolve these issues, but I don't think that is going to work reasonably either. The problem is that while that would reconcile the differences between, PEP 503 doesn't provide any mechanism to pass information like the summary that we print alongside each result above. Speaking with my PyPI hat on, I would be very opposed to adding such information to the PEP 503 repository API, because it would bloat the responses and have them take up more bandwidth for a very minority edge case. The other problem is that the ``PackageFinder()`` API itself doesn't fall back to ``/simple/`` anymore, but that's resolvable but the larger issue with that is that ``/simple/`` is 7MB large as of right now, and that is likely to continue to grow, having ``pip search`` issue a 7MB http request is a pretty crummy experience.
So that leaves us in a bit of a sticky situation. The current implementation is confusing and practically speaking only searches PyPI and not anywhere else, but our best path forward for resolving that is a non-starter due to other concerns.
So I think we should just rip the bandaid off and deprecate and eventually remove the ``pip search`` command. The only other alternative I can really think of that would actually resolve this, is to switch to using ``/simple/``, but that would then mean getting hit with a 7MB download just to try and search.
Thoughts @pypa/pip-committers?
1 个赞
covid-19 先结束,还是 pip search 先修复?
希望 Covid-19 快点结束(刚刚又被封2天,才放出来 ), pip search 不修也罢,pip-search 界面更加好看。