classification
Title: ensurepip should work with pythonw.exe
Type: Stage:
Components: Installation Versions: Python 3.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: Marcus.Smith, dstufft, ncoghlan, paul.moore, steve.dower
Priority: normal Keywords: patch

Created on 2014-10-26 20:24 by steve.dower, last changed 2014-10-26 22:47 by paul.moore. This issue is now closed.

Files
File name Uploaded Description Edit
ensurepip.patch steve.dower, 2014-10-26 20:24 review
Messages (7)
msg230032 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-10-26 20:24
I'd like to be able to run ensurepip in the 3.5 installer with pythonw.exe, to avoid having the console window appear.

Unfortunately, pip requires a valid value for sys.__stdout__. This patch adds a dummy value for __stdout__ that allows pip to be installed/uninstalled with pythonw.

I see no reason not to check this into default now, so just seeking a quick review from the module owners. I can also backport it to 3.4 if that's thought to be worthwhile, but I don't think the installer for 3.4 will be updated to use pythonw, so it probably doesn't matter.
msg230033 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-26 20:26
This looks OK to me.

I'm not a Windows person are there changes in pip that would make sense to make it work without this patch?
msg230040 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-10-26 20:50
I think the only thing pip could do is to stop using print(), which is not a reasonable request.

It may be reasonable to change pythonw to use dummy IO streams by default, but that may cause programs to print() messages expecting the user to see them. It's also likely a breaking change for many programs, so I do think handling the ensurepip case like this is best.

Just realised that I probably ought to make the same fix for __stderr__, in case pip succeeds but tries to write a warning there that causes the installer to detect a failure. Assume an equivalent line of code to set stderr/__stderr__ if needed.
msg230041 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-26 20:53
The development version of pip switches things over to using the Python logging framework instead of a homegrown one which more or less relies on print(). Probably we could detect if we don't have a stdout and just not output anything? People can pass a parameter to redirect it to a log file or whatever too.
msg230043 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-10-26 21:03
That change sounds like it'll be enough, and I'd be surprised if the logging module doesn't already handle the case with no streams.

(Aside: it'd be nice for ensurepip to have a log file parameter that can be passed through.)

I'll hold off on merging this in now, though I'll keep it in my branch until we get a pip update.
msg230047 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2014-10-26 22:44
This looks reasonable to me.
msg230048 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2014-10-26 22:47
Wait, sorry I misread the discussion (long day here). If we can do this in pip yes that would be better. It looks like we can detect when we're being run via pythonw by checking if sys.stdout is None.
History
Date User Action Args
2014-10-26 22:47:45paul.mooresetmessages: + msg230048
2014-10-26 22:44:05paul.mooresetmessages: + msg230047
2014-10-26 21:03:08steve.dowersetstatus: open -> closed
resolution: wont fix
messages: + msg230043
2014-10-26 20:53:05dstufftsetmessages: + msg230041
2014-10-26 20:50:44steve.dowersetmessages: + msg230040
2014-10-26 20:26:38dstufftsetnosy: + paul.moore, Marcus.Smith
messages: + msg230033
2014-10-26 20:24:46steve.dowercreate