[Python-Dev] Adding a Pip GUI to IDLE and idlelib (GSOC project)

[Terry Reedy]

Summary: There are two prospective Google Summer of Code (GSOC) students 
applying to work on writing a gui interface to the basic pip functions 
needed by beginners.  I expect Google to accept their proposals.  Before 
I commit to mentoring a student (sometime in April), I would like to be 
sure, by addressing any objections now, that I will be able to commit 
the code when ready (August or before).

Long version:

In February 2015, Raymond Hettinger opened tracker issue
"IDLE to provide menu options for using PIP"
https://bugs.python.org/issue23551#msg236906
The menu options would presumably open dialog boxes defined in a new 
module such as idlelib.pipgui.  Raymond gave a list of 9 features he 
thought would be useful to pip beginners.

Donald Stufft (pip maintainer) answered that he already wanted someone 
to write a pip gui, to be put somewhere, and that he would give advice 
on interfacing (which he has).

I answered that I had also had a vague idea of a pip gui, and thought it 
should be a stand-alone window invoked by a single IDLE menu item, just 
as turtledemo can be now.  Instead of multiple dialogs (for multiple 
IDLE menu items), there could be, for instance, multiple tabs in a 
ttk.Notebook.  Some pages might implement more than 1 of the features on 
Raymond's list.

Last September, I did some proof-of-concept experiments and changed the 
title to "IDLE to provide menu link to PIP gui".  In January, when Terri 
Oda requested Core Python GSOC project ideas, I suggested the pip gui 
project.  I believe Raymond's list can easily be programmed in the time 
alloted.  I also volunteered to help mentor.

Since then, two students have submitted competent prototypes (on the 
tracker issue above) that show that they can write a basic tkinter app 
and revise in response to reviews.

My current plan is to add idlelib/pipgui.py (or perhaps pip.py) to 3.5 
and 3.6.  The file will be structured so that it can either be run as a 
separate process ('python -m idlelib.pipgui' either at a console or in a 
subprocess call) or imported into a running process.  IDLE would 
currently use a subprocess call, but if IDLE is restructured into a 
single-window, multi-tab application, it might switch to using an import.

I would document the new IDLE menu entry in the current IDLE page. 
Separately from the pip gui project, I plan, at some point, to add a new 
'idlelib' section that documents public entry points to generally useful 
idlelib components.  If I do that before next August, I would add an 
entry for pipgui (which would say that details of the GUI are subject to 
change).

Possible objections:

1. One might argue that if pipgui is written so as to not depend on 
IDLE, then it, like turtledemo, should be located elsewhere, possibly in 
Tools/scrips.  I would answer that managing packages, unlike running 
turtle demos, *is* an IDE function.

2. One might argue that adding a new module with a public entry point, 
in a maintenance release, somehow abuses the license granted by PEP434, 
in a way that declaring a public interface in an existing module would 
not.  If this is sustained, I could not document the new module for 3.5.

Thoughts?

-- 
Terry Jan Reedy