Hacker News Reader

Comment by nilamo | Hacker News Reader

Pip is broken and has been for years, they're uninterested in fixing the search. Or even removing the search or replacing it with a message/link to the package index.

imo, if pip's preference is to ship broken functionality, then what is/is not shipped with pip is not meaningful.

View on HN

This is not a charitable interpretation. The more charitable read is that fixing search is non-trivial and has interlocking considerations that go beyond what pip's volunteer maintainers reasonably want to or can pick up.

(And for the record: it isn't their fault at all. `pip search` doesn't work because PyPI removed the search API. PyPI removed that API for very good reasons[1].)

[1]: https://github.com/pypa/pip/issues/5216

That was 7 years ago. If it's not coming back, the CLI should make that clear, instead of giving a temporary "cannot connect" message that implies it could work, if you wait a minute and try again.

It was three years ago; 2018 is when they considered removing the command, not when the search API was actually removed from PyPI.

And this is part of the interlocking considerations I mentioned: there are private indices that supply the XML-RPC API, and breaking them doesn't seem justifiable[1].

Edit: fixed the link.

[1]: https://github.com/pypa/pip/issues/5216#issuecomment-1235329...

Does that seem like a real solution to you? That it's ok to represent a never-functional operation as one that might maybe work? ...because it could work of you jump through a bunch of undocumented hoops?

It's so wild to me that so many people are apparently against making a user-friendly update. The whole thing seems very against pep8 (its surprising, complicated, non-specific, etc)

I don't know what to tell you; I just gave an example of it being functional for a subset of users, who don't deserve to be broken just because it's non-functional on PyPI.

Nobody wants anything to be user-unfriendly. You're taking a very small view into Python packaging and extending it to motives, when resources (not even financial ones) are the primary challenge.

Is code to detect when the user is not in that subset and say that it doesn't work really really hard for some non-obvious reason? If the default case for the vast majority of users doesn't work, it doesn't seem like printing a more useful error message to them should be that hard.

> it doesn't seem like printing a more useful error message to them should be that hard.

I think the existing error message is useful:

    $ pip search foo
    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.

It says (1) what failed, (2) why it failed, and (3) links to a replacement, and (4) links to a deprecation explanation. That last link could maybe then link back to the pip issue or include some more context, but it's a far cry from being not helpful.

That is a nicer message than I remember. I don't have an issue with that. It let's you know it doesn't work, that it will never work, and provides links to an alternative and more information.

It either used to do fewer of those, or my memory is Swiss cheese, but I remember needing to search for the why's and alternatives.

There was a period when the error was a stack trace. But that was pretty brief, and happened before PyPI moved more "officially" towards not supporting the search API.

I think part of the confusion here (which is reasonable IMO) is that pip has a huge version tail, and so people report error messages and behaviors that have been fixed for years. This is one of the challenges that I think gets under-appreciated about pip's maintenance.

Your comment gave me an flashback to when I started programming and drag and dropped downloaded python packages into the packages folder instead of installing them.

Reply on news.ycombinator.com