-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teach pip
to play along with head
unix-command
#5721
Conversation
pip | head
pip | head
src/pip/_internal/utils/logging.py
Outdated
"""Ignore `BrokenPipeErrors` on `flush()`.""" | ||
try: | ||
self.flush() | ||
except BrokenPipeError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BrokenPipeError wasn't defined in Python 2, so you'll need something different for that case
Well, you said that |
pip | head
pip | head
8afa21a
to
efc5c51
Compare
src/pip/_internal/utils/logging.py
Outdated
def flush(self): | ||
"""Ignore `BrokenPipeErrors` on `flush()`.""" | ||
try: | ||
self.flush() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be super(..., self).flush()
.
news/4170.bugfix
Outdated
@@ -0,0 +1,2 @@ | |||
Teach pip's logging-handler to stay calm on `BrokenPipeError`, probably *stderr* redirected to :command:`head`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be something like:
Avoid printing a Traceback when a broken pipe is encountered in stderr (like when piping through `head` on Unix)
Any idea where to attache the TC? |
@ankostis What's TC? |
299c751
to
64dcb57
Compare
The one suggested by @pfmoore.
|
I'm guessing "test case". I don't really have any good feel for where would be the best place in the test suite for something like this, so I can't really suggest a location, I'm afraid. |
The most relevant TC is I will put it here, and someone may rename this test-module, if you don't have any objections. |
You can add that test there and rename that file to test_logging.py. |
Without the TC yet, travis is ok. Note that |
Extend it to renaming the file? No worries. I'll be okay with doing it myself in a follow up. |
No, ididn' mean that., i can rename it the test-case module. I guess |
64dcb57
to
025f3cc
Compare
025f3cc
to
1be0063
Compare
@@ -136,12 +137,25 @@ def get_win32_calls(self): | |||
} | |||
return dict() | |||
|
|||
def _flush(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've modified a vendored library - colorama. What's the reason you had to do this?
pip actively avoids patching it's vendored libraries in favour of making changes upstream and absorbing those changes when a new release is made.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As explained it also in conversation, patching logger is not enough.
In windows, as soon as you patch it and try to redirect to head, that this the next point where it fails on broken-pipe.
And not only it simply fails, but if you ignore also at that point pipe-errors, you then get a mysterious EINVAL OSError:
File "pip\_vendor\colorama\ansitowin32.py", line 143, in _flush
self.wrapped.flush()
OSError: [Errno 22] Invalid argument
If you ignore also that, then it works.
Now i'm also surprised that Colorama has not fixed it, and i search a bit and did not fimnd anything related reported.
Certainly if it is fixable, it should be fixed there.
aa65d5d
to
967f2d0
Compare
967f2d0
to
2804481
Compare
acc2010
to
3a5c131
Compare
3a5c131
to
74dcba3
Compare
74dcba3
to
bd530f7
Compare
bd530f7
to
7f4ec24
Compare
c82fdcd
to
28beeeb
Compare
bc on Windows it breaks with OSError(errno.EINVAL) after pip has broken. + Fix a bit the TC according to PY2 behavior.
b84dfe7
to
28beeeb
Compare
Ok another day, another look....i abandoned 2 new TCs have been introduced in the renamed
PR graduated from [WIP] (but still not decided whether to push upstream fix to |
Note: At the moment have pushed one commit back in time from b84dfe7, and wait for Appveyor to validate it. |
tests/functional/test_logging.py
Outdated
"Expected no color in output" | ||
|
||
|
||
def _run_and_brake_stdout(cmd, read_nchars=1, check=False, **popen_kw): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Spelling is "break" not "brake".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
tests/functional/test_logging.py
Outdated
|
||
def _run_and_brake_stdout(cmd, read_nchars=1, check=False, **popen_kw): | ||
""" | ||
Launch Popen, brake stdout, ignore returncode and return stderr. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
if check: | ||
assert not proc.returncode, (proc.returncode, cmd, err) | ||
|
||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually seems way too complicated. I'd be concerned that there are bugs in the test code here. Not that I can see any, just that it's not obvious what it's testing.
To reiterate what I said originally, what's wrong with something as simple as
text = subprocess.check_output('pip --help | head`, stderr=subprocess.STDOUT, shell=True)
assert 'Broken pipe' in text
You may have to only run the test on Unix, as Windows doesn't have a head command by default, but I wouldn't be too worried about that. To be fair though, I'm not actually convinced that the broken pipe error is bad enough to be worth worrying about in the first place...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows doesn't have a head command ... but I wouldn't be too worried about that
No no, there's MSYS2 (posix) on appveyor (among others), head
wouldn't be a problem.
Testing on Windows is important. You see, i discovered the colorama
problem, captured by the TCs, (appveyor#1.0.3221), and fixed by the 2nd fix-commit.
what's wrong with something as simple as
subprocess.check_output('pip --help | head' ...
I've pushed the simplified variant you suggested, and the strange errors started.
Additionally, in Windows i'm infested by #3383 and cannot test cleanly locally, and going back and forth to virtualbox is tiring...
I remember these 2 days fighting them, my apologies, i don't remember all the nuances that made me turn around.
Any ideas?
BTW: pip --help
is not printing through logger, which this PR is about, but through argparse
(no?) - we need a command with many separate log-statements, like download
, or install
. Is there any other?
I'm not actually convinced that the broken pipe error is bad enough
I scratched my itch when i was fighting package/version resolution problems, and used head
to view just the few first lines of the logs, but still, a torrent of 5000+ lines scrolled down my console too quickly for Ctrl+C to work - i don't know how to say it, but a tool not going along with head
feels rude to me (hope it's not too impolite to say it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a tool not going along with head feels rude to me (hope it's not too impolite to say it).
Not at all, and if it caused you a problem and you were considerate enough to spend time fixing it for us, I'm very grateful. All I was trying to say was that I'm not a good judge of how much effort it's worth spending on this, as it doesn't bother me that much.
I understand about the annoyances testing. I don't know of a good answer - I do basically what you do, I push a WIP change and let the CI run the tests. What you can do, once you have a specific test that you want to work on, is run that test alone using tox -e py36 -- tests\functional\test_logging.py -k test_broken_pipe_logger
specifying the file and test name. That's usually fast enough to be workable.
I'll try to find some time tomorrow and look through the bugs you're hitting, and see if I can shed any light on them.
edc5a84
to
b096426
Compare
Created a new PR #5729 with the |
pip | head
pip | head
pip | head
pip
to play along with head
unix-command
Closing this for the same reason mentioned in PR #5729 (superseded by PR #5907, which was recently merged): #5729 (comment) Thanks for your contributions, @ankostis. |
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. |
Fix #4170: Override
ColorizedStreamHandler.flush()
to ignoreBrokenPipeError
exceptions.Note, it would be hard to make a test-case for it, no?