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