Implement better handling of pip errors

[cs01]

I came across this piece of negative feedback about pipx and I think reflecting on negative feedback is very valuable https://twitter.com/carltongibson/status/1353766968663429120

ansible ...
SOME LOAD OF NOISE ABOUT HOW SOMETHING BROKE WITHOUT ANY ADVISE ON A SIMPLE WAY TO FIX IT

Admittedly this isn’t a concrete error, but maybe there is something we can take from it. Perhaps an audit of all the error messages to ensure there is a succinct fix.

[itsayellow]

It's hard to know what he's experiencing with this level of detail... 😆

It could be that he's getting the pip error that we pipe through to the user when pip has a failure. Although in that case I'm not sure why virtualenvwrapper would work and pipx wouldn't.

[itsayellow]

I have often wondered about the utility of the pip errors we pass through. Especially with something that includes compilation steps, you can get pages and pages of "noise" as he says.

[itsayellow]

Or is he getting a problem while running ansible?

[itsayellow]

Also some of the buried comments from another user talk about how possibly the problem might be ansible with plugins. So it might be that something else in the same venv was needed and missing or malfunctioning.

[uranusjr]

The comment sounds weird to me as well (and I suspect Jeff Triplett felt the same, hence the inquiry). pipx is essentially virtualenvwrapper + symlinking commands to ~/.local/bin, so if virtualenvwrapper works for him but pipx does not, pipx probably isn’t a good tool for what he’s trying to do in the first place.

[cs01]

Thanks guys. If you think there is nothing further that needs to be done feel free to close. I just wanted to flag it in case there is anything we can take from it.

[itsayellow]

I am curious what people think about piping through the entire pip response in case of a pip error. For experienced users this can show what's wrong. But if you're not an experienced user it is easily overwhelming.

I've thought of the possibility of saving the full pip output into a separate error file in case of pip error, and then letting the user know where to find it. (possibly in pipx/logs.) However this might annoy the experienced users who just want to see what went wrong immediately.

We could also save the full pip output to a file, while try to grep it for the specific error to show to the user right away.

I've seen a lot of pages of pip error outputs when developing the slow tests that test many many packages, and I will say they were often overwhelming to me.

[cs01]

I think you are on to something. Pipx is trying to provide a layer of abstraction over pip, so the better we can do that the better the UX. I am thinking we can do a few things to help:

• only display the last n characters of pip output
• make the output visually distinct from pipx output, such as indenting, using a muted color like grey, etc
• Display path to full pip output for further investigation if desired
• If verbose is true, print it inline
• Do not add any new flags to pipx to tweak how this is handled since they will further complicate the api, and we should be able to set good enough defaults

[itsayellow]

I like that. I think it would be a significant improvement in UX.

Should we rename this Issue or start a new one?

[cs01]

Leaving in this one is fine if you want to rename it

[itsayellow]

I'm not sure I have the bandwidth to do this properly right now. Although I think it's a worthy endeavor.

[itsayellow]

Looking at the old artifacts from the CI "slow" tests, it seems that usually the most salient line from a pip session that ends in error is the one starting with "Failed to build". That line seems to show every package (main or dependency) that failed to build in that pip session.

This line seems to occur sometimes in stdout and sometimes in stderr. In general it seems that there pip outputs both a sizeable stderr and a sizeable stdout with somewhat different information in each, but I can't tell how it decides what output to send to which stream.

[itsayellow]

Well I just tried installing 'mayan-edms' in my macOS Python 3.9. It fails, but it never prints the string "Failed to build". 🤷 So maybe that phrase isn't universal or maybe pip has started to output different error messages.

[itsayellow]

Ah ok, it says "Failed to build" when wheel is installed. If wheel isn't installed it says other things.

Also, the pip option -q will prevent any stdout from being output, and also seems to prevent "Failed to build" from appearing in the pip output.