[Python-ideas] install pip packages from Python prompt

[Terry Reedy]

On 10/31/2017 12:21 PM, Ivan Levkivskyi wrote:
> I think it was proposed several times before, but I just wanted to 
> revive the idea that we could add
> a GUI interface to install/update packages from IDLE (maybe even with 
> some package browser).

https://bugs.python.org/issue23551.  I agreed with and still agree with 
Raymond's opening message in Feb 2015:
"In teaching Python, I find that many Windows users are command-line 
challenged and have difficulties using and accessing PIP. ... I would 
love to be able to start a class with a fresh Python download from 
python.org and effortlessly install requests and other tools without 
users having to fire-up a terminal window and wrestle with the various 
parts."

The one change I made in Raymond's proposal is that instead of having 
multiple IDLE menu entries tied to multiple IDLE functions invoking 
multiple pip functions, there would be one IDLE menu entry, perhaps 
'Help => Install packages' (plural intentional), that would invoke a 
standalone tkinter based gui front-end to pip.  'Standalone' means no 
dependency on IDLE code.  I don't think every IDE or app should *have 
to* write its own gui.  Plus, a standalone tkinter module could be 
invoked from a command line with 'python -m pipgui' or invoked from 
interactive python with 'import pipgui; pipgui.main()'.

In April 2016, after posting the idea to pydev list and getting 'go 
ahead's from Nick Coughlin and someone else, with no negatives, I 
approved Upendra Kumar's GSOC proposal to write a pip gui.  This was 
https://bugs.python.org/issue27051.  On June 20, Ned Deily and Nick 
Coughlin vetoed adding a pip gui anywhere in the stdlib since it 
depended on something not in the stdlib, and perhaps for other reasons I 
don't fully understand.

Looking back, I can see that I made two mistakes.

The first was proposing to use the public-looking pip.main after 
importing pip.  It is actually intended to be private (and should have 
been named '_main' to make that clearer).  As it turns out, the extra 
work of accessing pip through the intended command line interface (via
subprocess) is necessary anyway since running pip makes changes to the 
in-memory modules that are not reset when .main is called again.  So it 
might as well be used for every access.

The second was not requiring an approved PEP before proceeding to actual 
coding.

-- 
Terry Jan Reedy