Plainly indicate/implicate the package being installed for installation errors.

[chrahunt]

What's the problem this feature will solve?

If a user installs a package and there is an error, the actual cause may be the package itself. Currently it is not clear from the output that pip is delegating some parts of the installation process to the package (or a build backend). This is based on several issues raised in the pip issue tracker:

• "Failed building wheel for vowpalwabbit" #5023
• fail to install cairosvg #5694
• pip 19.1.1 (get-pip.py) fails to installing egenix-mx-base with a gcc error (older version works fine) #6609
• RuntimeError: Python version >= 3.5 required. #6667
• "pip install -e ." didn't works ----yolo installation problem #6942
• pip install gpg==1.10.0 not working on Windows #6960
• probably many others

To take one concrete example (#6667):

Collecting pandas
  Using cached https://files.pythonhosted.org/packages/b2/4c/b6f966ac91c5670ba4ef0b0b5613b5379e3c7abdfad4e7b89a87d73bae13/pandas-0.24.2.tar.gz
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      [... long traceback ...]
ERROR: Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-rC8dFo/pandas/

In this case, the first place a user should consider looking is the pandas issue tracker. In order to get that from the output, they would need to understand how Python packaging works which isn't (and shouldn't) be a requirement for consuming Python packages.

Describe the solution you'd like

When we delegate some part of the installation to a package (via setup.py) or to a build backend, we should print a message that leads the user to consider the package being installed as the more likely cause than pip. For example:

ERROR: Error installing package "". Examine the error above and check their support channels.

Some prior art:

• npm: npm ERR! package.json This is most likely not a problem with npm itself.
• Conda: An error occurred while installing package "name"

One obvious issue with this approach is that package maintainers would get users creating issues for pip bugs. Personally I think this concern is outweighed by the following:

1. as a package maintainer, I would want to know that users are having an issue consuming my package even if the installer itself is the cause
2. if an issue in pip is the cause of a problem reported to a package maintainer, then it may be more likely that the package maintainer makes the issue against pip, which would probably have more details or simpler reproduction steps to emphasize that the package itself isn't the cause
3. a user may be using a very old version of a package or using the package in an unsupported way, which would be more obvious to package maintainers than pip maintainers
4. package maintainers have expertise in their package setup, and should be able to identify more quickly whether the issue is with the package itself , the build backend, or pip

Another issue would be misdirecting (possibly new) package developers. If the error occurs while installing a requirement given as a local path, we could instead direct users to setuptools or the relevant build-backend, which could help situations like #6350. IMO this can be addressed as a separate issue to keep this one simple.

Alternative Solutions

• Improve documentation (or improve placement of existing documentation) to give enough context on Python packaging so any user would understand the current output as-is.

Additional context

• As suggested by @pradyunsg in #6667 (comment).

[itsayellow]

I think this comment is on-topic, apologies if it's not quite:

I'm a maintainer of pipx, and am looking into parsing the pip output for errors to distill and give back to our user in a more friendly format. What I'm really trying to extract is just a simple list of every dependency that failed to build. Unfortunately I'm not sure there is any single error message I can look for. There seems to be a plethora of different kinds of failures and their associated error messages from trying to install various packages.

If wheel is installed, it seems as though "Failed to build" is a good string to look for. But not if wheel isn't installed.

What I'd really like is some message from pip that I can depend on being present for every package that fails to install. All of the detail is great, but at the end it would be nice for pip to come back in with something like:

pip: package 'Pillow' failed to install.

I understand that error attribution back to the package and not to pip helps prevent users from assuming an installation failure is a pip bug. But identifying clearly every failed package would also be invaluable for pip users. And for applications parsing pip output, it would be nice to have clear, reliable messages to look for.

[uranusjr]

If wheel is installed, it seems as though "Failed to build" is a good string to look for. But not if wheel isn't installed.

I would recommend always installing wheel instead. Installing without wheel (or PEP 517) is deprecated, so it’d be best for pipx to avoid it in any case.

[itsayellow]

Good to know. I have seen cases where wheel is installed, but I still don't see the magic phrase "Failed to build" even when something did fail to install. So it would be nice if besides all of the debug output pip would show the same error message signifying simply which dependency(s) failed to install.

[pradyunsg]

This is done now, as part of #10795.