Handle BrokenPipeError gracefully (#4170)

[cjerdonek]

This shows an alternative way of addressing #4170.

Here is sample output:

$ pip list | head
Package           Version    Location                                                                                  
----------------- ---------- ----------
CacheControl      0.12.5     
...
idna              2.7        
ERROR: Pipe to stdout was broken
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

And with more verbose output:

$ pip -v list | head
Package           Version    Location                                                                                   Installer
----------------- ---------- ------------
CacheControl      0.12.5
...
idna              2.7
ERROR: Pipe to stdout was broken
Traceback (most recent call last):
  File "/.../logging/__init__.py", line 996, in emit
    self.flush()
  File "/.../logging/__init__.py", line 976, in flush
    self.stream.flush()
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../pip/_internal/cli/base_command.py", line 144, in main
    status = self.run(options, args)
  File "/.../pip/_internal/commands/list.py", line 145, in run
    self.output_package_listing(packages, options)
  File "/.../pip/_internal/commands/list.py", line 211, in output_package_listing
    self.output_package_listing_columns(data, header)
  File "/.../pip/_internal/commands/list.py", line 234, in output_package_listing_columns
    logger.info(val)
  File "/.../logging/__init__.py", line 1306, in info
    self._log(INFO, msg, args, **kwargs)
  File "/.../logging/__init__.py", line 1442, in _log
    self.handle(record)
  File "/.../logging/__init__.py", line 1452, in handle
    self.callHandlers(record)
  File "/.../logging/__init__.py", line 1514, in callHandlers
    hdlr.handle(record)
  File "/.../logging/__init__.py", line 863, in handle
    self.emit(record)
  File "/.../logging/__init__.py", line 998, in emit
    self.handleError(record)
  File "/.../pip/_internal/utils/logging.py", line 133, in handleError
    raise BrokenLoggingStdoutError()
pip._internal.utils.logging.BrokenLoggingStdoutError
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

[pradyunsg]

I like the approach here.

[pradyunsg]

@cjerdonek Is this still a WIP?

[cjerdonek]

@pradyunsg I was hoping to add some higher-level tests, like testing the exception handling in base_command.py. Currently just the logging aspect is being tested. But otherwise I'm okay with things.

[BrownTruck]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will be eligible for code review and hopefully merging!

[cjerdonek]

This is now ready to be reviewed.

[cjerdonek]

Hi @pradyunsg, I just wanted to flag this PR for you. Is it okay for me to add this to the milestone for the upcoming release? The non-test code portion had been implemented and done for a while, and it now has very good test coverage. This includes a thorough end-to-end test (using subprocess) passing on all platforms. It is a bug fix for a quite visible problem when it happens

[BrownTruck]

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will be eligible for code review and hopefully merging!

[pradyunsg]

Hi @pradyunsg, I just wanted to flag this PR for you.

Whoops! I haven't been checking my GitHub notifications properly.

Is it okay for me to add this to the milestone for the upcoming release?

Yes, it is. Let's include this in the next release.

---

As an aside, the way we've mostly flagged things for being added to a release since I've been around, is to simply add them to the release milestone and leave a comment before/after adding it. If the feature is not a blocker, the RM will remove it when the release comes. This is the sort of "institutional knowledge" that I think we should start documenting in out

GitHub mentions (thanks notifications) usually get buried.

[pradyunsg]

@cjerdonek this is a super polished PR, with nice comments in the right places and understandable code. Nice work! 🎉

[cjerdonek]

Thanks a lot for merging and for the nice comments, @pradyunsg. This was one of my more involved PR's, so I appreciate it!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.