In teaching Python, I find that many Windows users are command-line challenged and have difficulties using and accessing PIP.  In the spirit of what Tortoise has done for version control, I propose that menu options be added for PIP.

PyPI (Python Package Index)
---------------------------
* Ensure pip / Upgrade pip
* Show installed packages (freeze) (and give options to update or remove)
* Install from requirements file (install -r)
* Search for package
* Install package
* Upgrade package (install -U)
* Uninstall package
* Change default repository (default pypi.python.org)
* Change default install directory (in case the user doesn't have admin rights)

This change would be a major step forward in making the PyPi accessible by people who lack the skills or inclination to wrestle with 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.

I don't know if this should be part of IDLE or not, but I've long wondered if we should make a GUI frontend for pip. To be clear, I'm not against this being in IDLE either, but just saying I've thought about making a pip-gui project in the past, I just haven't had the time or motivation to really do it.

Raymond, I have had a very vague idea of doing something like this.  Thanks for posting something more concrete.  I share the sentiments of your last sentence.

Reading Stackoverflow, it is apparent that some people with two+ Python versions do not know that a package must be installed for each version of Python, and have less idea how to install for the non-default version.  (All I know is to cd to pythonxy, or maybe pythonxy/scripts and run pip from there, or something like that.)  Running from Idle (x.y) would take of this.

Donald: at Raymond's behest, Idle now has a menu entry to run turtledemo, a separate application that is useful to beginners, in part to make turtledemo more visible. pip_gui could easily follow the same model.  No direct interaction with the Idle shell or edit windows is needed.  If you are less familiar with tkinter than I am, I would help with the gui part.  As hinted above, I am not the one to decide on menu options and write the implementation functions.

I'm unlikely to have the time or motivation to do this anytime soon (just to be clear). I would be able to advise anyone who does feel like doing it the best ways to interact with pip itself though.

Thinking a bit more, the Idle entry point could be one entry, 'Install Packages' or 'Manage Packages' on the Options menu (or maybe Help menu).  I am not sure that the new window would need a submenu, as I think everything listed in the opening post could fit in a large window.

Hi,
I would like to work on this. Give me a day or two to come up with my design plan, for feedback.
Let me know please if this feature addition is being considered.

Yes, this would complement your checker patch from last summer.  It would solve the issue of how to tell or help people, especially beginners, install packages to run with the checker.

Idea for the package manager: include an option to duplicate a set of installed packages from one version to another. A recent SO question (paraphrased): "Started with 2.7, installed multiple packages, added 3.4, can't use packages.  HOW???"  Current answer, with easily missed details, something like: "Packages must be installed for each version.  Use PIP to make requirements.txt (sp?) package list from 2.7 and use that to install same to 3.4."  Nicer answer: use option that gets details right.  Perhaps list could be checked for availability in 3.4.  Or displayed in text widget to be edited.

I look forward to your proposal.

For the initial version here is what I plan to code:
A single package manager entry in a suitable menu. This would open a dialog window
containing options for (inspired from msg236906).
    1. Show installed packages(freeze)
        This menu would have options to update and remove the said package.
    2. Install package 
        The user may specify an url, paste a requirements.txt type file or
        point to a requirements.txt file.
    3. Settings
       Change install directory 

    The user will be able to update/revert to a specific version.
    Incase of an error, the error message which would be have been printed to the terminal will be displayed to the user in a dialog box.

Any changes made to packages would be for the version using which IDLE was started.

Also, what do you feel about support from non-PyPI repositories like github? Do we intend to support everything pip supports or only a subset of it (say PyPI)?

For this initial version, I would like to keep cloning across versions for later version. For now these are the things I would like to get right first.

On Windows, I think we should consider directly supportting
http://www.lfd.uci.edu/~gohlke/pythonlibs/
Unofficial Windows Binaries for Python Extension Packages
When possible, this has 2.6, 2.7, 3.3, and 3.4 binaries for 32 and 64 bits.

I and others use this site, but beginners would not know to use it.  Since last summer, Christoph has switched nearly all files from .zip to pip-installable .whl.  The site says to download and point pip to the local downloaded copy, but I presume pip can be directly pointed to the site.

PS. I am fine with your initial plan.

I really do think we should support Christoph's site.  It has saved me many a headache over the years.  For beginners it's also got to be preferable to seeing the rather cryptic "Unable to find vcvarsall.bat" message, plus how many of them want to install VS?

The proof of concept is almost ready.
I have a couple of questions to anyone familiar with pip api (and on windows for question 2)

1. Is a restart of the interpreter absolutely required for pip.operations.freeze.freeze() to reflect changes?(install/uninstall)?

2. (Windows particular) Is a permission similar to sudo required to install packages using pip? If not, would it be OK to install only to user home director in *nix? Doing so would be allow code to be same across platforms. It would also prevent asking the end user where they want the package to be installed.

I think that on Windows you might have to assume that the user has the rights to install to site-packages, regardless of where the Python version is installed.  Please see https://docs.python.org/dev/using/windows.html for the installation screen for 3.5.  If this is not the case Raymond's final requirement "Change default install directory" would not help as the user still needs to change the environment to get Python working, or have I missed something?

This is really needed. A number of recent threads on python-list indicate that beginners are having problems with using pip.

Donald, can you answer Saimadhav's questions two messages above?

Saimadhav, can you post whatever you have done so far?

Nick, Paul, Marcus, can any of you answer Saimadhav's question 3 messages up?

pip doesn't really support being called as an API, there's been requests for it before but nobody has yet come forward to specify what parts in particular they need. The practical effect of this is that there's no backwards compatibility promises for anything you import from pip currently. I would suggest using a subprocess to communicate with pip unless you can define what operations you need so the pip developers can settle on a real public API for them.

As for your actual questions:

1. I'm pretty sure it requires restarting the process because pkg_resources has a cache and pip currently isn't designed in a way that it assumes you're going to freeze in anything but it's own process.

2. I think this depends on what version of of Python it's being used with and where the user installed it to. I think Steve Dower has switched Python 3.5's default install location to Program Files which does require it to be run as an administrator if you want to install into the site-packages instead of the user packages directory.

Can we use ideas from https://sites.google.com/site/pydatalog/python/pip-for-windows ?

I actually made the default per-user, specifically for cases like this. With a default install that the current user has done, pip does not need to be run as admin.

If the system administrator has installed Python for all users, then --user needs to be specified to run without admin. (Could the admin add config to pip for all users to make this the default? I know we discussed it - don't remember what the result was.)

Pip's rather extensive command-line API can also be used as a code API. The signature of pip.main is (args=None), where args = sys.argv[1:] if not passed. I presume this will not change. Reusing the command-list API had the advantage of reusing the existing docs, help output, and knowlege of how to use pip.

The API is to run 'status = pip.main(args)', where args is a list containing quoted versions of the command-line args, the same as one would pass to subprocess.Popen.  Output is strings written to stdout (and stderr), which can be captured with StringIO. While not as nice as getting, say, a list of strings from a list_command function, I consider this better than repeatedly calling Popen and getting encoded bytes (in whatever encoding) from pipes.

I tested this with list, show pip, help install, and install --upgrade pip.  After a shell restart,  import pip imported the new version. I am working on a wrapper for the pip.main call.

Yea ``pip.main(args)`` won't change. I'm not sure how well parts of pip will handle being in a persistent-ish process, but the API itself will work.

There is a "site" config file which works for all installs on that particular machine, there is not a per Python configuration file, though I don't see why we couldn't add one.

The persistence issue is why I tried several calls before posting above. I am hoping that none of your command functions leave pip unusable, or if they do, you would be willing to have them fixed.

Attached is promised wrapper.

Yea, we'd be willing to fix things where we can. I think the biggest problem you'll run into is probably going to be pkg_resources and it's module scoped cache of the sys.path and what items are installed.

You are right. While multiple info requests work, I found a test that fails. 'list' showed that I had Pillow 2.7.0.  'install -U Pillow' updated to 2.9.0'. 'list' again still showed 2.7.0. 'show Pillow' then failed because 2.7.0 could not be found.  After an install, we need to delete the one local reference to pip(.main), which should remain the only reference, and reload to refresh that cache.

There is an obscure bug in either python, pip, or tem_pip such that runpip('-h') silently crashes python in both console and Idle. I will try to localize it.

Hi Terry,

Unfortunately, I had to perform a system reinstall, which wiped out the patch.

I dont mind doing it again, but it might take until the weekend to complete.

Also, now my questions from earlier are answered, it should be easier.

On python-ideas, Wes Turner reported Stallion, a visual (browser) + command line package manager interface. I believe it uses pip 'under the hood'. http://perone.github.io/stallion/ has screenshots that can give gui design ideas, though these are more elaborate than what we need. Package at https://pypi.python.org/pypi/Stallion

I believe for beginners it's not difficult to enter "pip install package". The trouble is with opening the command prompt, knowing about PATH and different Python versions etc.

Terry mentioned GUI development to be more expensive. What about providing a special command for IDLE shell, similar to IPython's magic commands:

%pip install package

Another (more general) alternative: provide a menu item "Open system shell for this Python version", which opens a terminal window with correct Scripts or bin folder in path.

If anything was to be copied from IPython, then the system shell access feature might be worth considering: http://ipython.readthedocs.org/en/stable/interactive/reference.html#system-shell-access

However, a command to launch a suitably configured shell session could be a better way to go, as it still helps to clearly introduce the difference between the "Python shell" and the "system shell", while avoiding teachers needing to explain several different sets of instructions for different operating systems.

Writing something takes more work than not writing something, but I never used the word 'expensive'.  I definitely think a there should be a tkinter-based pip gui.  Since there would be no needed interaction with IDLE internals, it should be a stand-alone module run in a separate process.  (The difference from a dependent module is trivial -- use Tk rather than Toplevel for the main window and add root.mainloop().)

It occurs to me today that the gui should not necessarily be tied to working with site-packages for a particular version of Python but could be based on a ttk Notebook with a tab for each installed version of Python.  (I assumes that discovery method of py can be reused or extended.)  That should make it easy to compare what is installed for different versions and to copy a set of packages to a new version.

As for magical syntax: I believe Guido has vetoed that idea as part of his admonishment that IDLE should not compete with IPython, PyCharm, etc.  In any case, Shell's visible input syntax so far been limited to the Python syntax of the console interpreter.  I am not inclined to change this. On Windows, IDLE's Shell effectively replaces the console interpreter for many users.

Adding a System Shell option to the run menu is a separate issue, which I have added to my private list.  Making the console easier to access would not solve all the problems of using pip directly and would not have the added benefits of a visual display.

In case "Open system shell" happens someday, here's my take on this: https://bitbucket.org/plas/thonny/src/master/thonny/plugins/system_shell/

It's a plugin for my beginners' IDE Thonny (http://thonny.cs.ut.ee). It creates a menu item which opens system terminal with current interpreter's binary folder(s) prepended to the path. As there may be several Python commands on path (eg. python and python3 in /usr/bin) and short pip command may be on path only for another version, a script gets automatically executed in this new terminal, which detects and tells user the commands to use (see attached screenshot)

On python-list, Chris Angelico reported 2 other problems when running something like "import pip; pip.main(['install','psycopg2'])" from IDLE.  Both can be worked around in a pipgui program.

1. pip displays a progress bar by sending to stdout a sequence of strings something like '#', '\r##', '\r###', ..., '\r###...###'.  When IDLE sends these on to the tk text widget, they are displayed as above.  '\r' displays as '\r' and does not cause a 'return'.

pipgui would already be monitoring and parsing pip output to display information in appropriate widgets, so it could look for and interpret whatever pip actually does send.

2. pip has a bug.  When installing a non-wheel, it may unconditionally execute "s.decode(sys.__stdout__.encoding)".  sys.__stdin__, etcetera, are documented as sometimes being None, https://docs.python.org/3/library/sys.html#sys.__stdin__, and None does not have an 'encoding' attribute.  The workaround, until this is fixed, is for pipgui to rebind sys.__stdout__ to an object that at least has a sensible .encoding.  I would grep the entire pip source other '__std.*__' uses to see if more is needed.

I am trying to make a Tk based GUI for pip package manager. In reference to msg256736, I am confused about the discovery method mentioned. Is there any way already implemented to detect the Python versions installed systemwide?

Moreover, how to manage the non-standard installation of Python by users? I think in that case, it would be very difficult to detect the Python versions installed in the user's system. In addition to it different tools used for installation of Python generally end up in installing in different folders or paths. 

Therefore, initially what functionality should I try to implement in it? Can anyone please suggest me?

I think an initial version of a pip gui need only install to the Python version running it.

The py launcher must discover some version of 'all' Python installs to choose, for instance, the latest 3.x version.  I do not know the details, nor which system py.exe runs on.  I was suggesting looking into the details after a first version.

A few days ago Steve Dower reported on pydev list how PSF installs on Windows register themselves in the registry (the keys used).  He also proposed a standard convention for other distributions to register, if they wish be be discovered by other apps, in a way that does not interfere with the entries for PSF installations.

Upendra, are you an intended GSOC student or simply a volunteer?  I am asking because, in the absence of submissions in nearly a year, I proposed on core-mentorship that this might be a good GSOC project.  I will not reserve this for GSOC if someone else is actually going to submit something.  But I also do not want to withdraw the idea unless someone is.

@Terry, I am an intended GSOC student and I came through this idea of developing a GUI based on Tkinter in the python core-mentorship mailing lists. You highlighted/mentioned this issue in the mailing list.

I trying to write the Tk application for the pip package manager. It is in very initial stage, with none of the functionalities implemented yet. I have attached the current state of code written by me. I have also included the wrapper provided by Terri for pip command line. 

Please can someone review my current code , if I am on correct path? If there are some objections to my coding style and the structure of program, please do tell me.

On idle-dev, Beni Cherniavsky-Paskin suggested that easily installing into a virtualenv would be a useful option, especially in semi-locked down education setting.  I probably agree, as a follow-on feature, but am barely familiar with venvs.

@Terry, I am also a GSOC 2016 participant. I would also like to work on this project. I had spent a few days to learn the tkinter library and finally finish some code for this project. Hope you can help to review it and giving some feedback. As for the virtualenv that you mention, how about I just let the user decide the path of the pip that they want to use by making a setting for path in menubar? I also design the prototype of the PIP gui. Please give me some review about those design. If you have any idea to improve it, feel free to comment!

Upendra and Eric: I look through and successfully ran both your files as they are, without change.  You both show a basic ability to write a simple tkinter app.

Upendra's is more complete as a demo because a) it has two tabs that I can switch between, even though the second is blank, and b) the first tab shows real data -- the list of installed packages on my system.  Eric, if you submit a proposal for this project, I would like to see these upgrades (without copying, of course).

Style nit: I don't like 'import *' and prefer 'as tk' or 'import Tk, Frame, ...'.  This choice partly depends on whether one prefers to use for options the named constants like EXTENDED or literal strings like 'extended'.  You don't need to rewrite now as long as you are *willing* to change, perhaps after discussing which alternative to use, if selected.  Eric: classes should be capitalized, but not all caps.  'Pip' would be fine.  In general, I want to follow PEP8 for new code.

 At least as important as style is structuring for testability, which IDLE is not :-(. Collecting data and displaying data should literally be separate functions: a get_data and a display_data.  (An extra reason to do this in the stdlib context is that only a small subset of CPython buildbots have graphic screens and run gui tests.)  Another change would be to replace

Get_data sends a request to pip and parses the output strings into a Python data object.  Its unittests would use a mock-pip that returns output copied and adapted from real pip request.  The unittest would then check that the data object equals the expected object.

Display_data receives the data object and changes the display.  Testing this is trickier.  It requires the 'gui' resource.  An initial test is that it run without raising an exception.  Some other checks can be automated.  Checking that the display 'looks right' has to be done by a human.

Thank @Terry for your suggestion. I have been working on this few hour to fix and improve the code. I have also add some new feature into the application. Hope you can help me to review it again. Thank.

About the proposal, please help me to review it if you have free time.

I also change some of the design like instead of showing the installed package information beside the list, I think that it will be better to show the package information on a new pop up window. You can try to double click the list of search tab and installed package tab. It is functional now.

After running the code, I want to stick with details in the same window.  The tab should be a Frame with a PanedWindow on top with list frame on left and detail frame on right.  The buttons would be under the paned window.  Run Lib/turtledemo/__main__.py either from IDLE or with 'python -m turtledemo' to see an example.

Eric: make sure you read my response to Upendra on core-mentorship list: "Inquiry about the "PIP GUI Project".

Raymond and Donald: I am seriously considering mentoring this as a GSOC project next summer.  Can I count on at least one of you occasionally reviewing the design and functioning of interim submissions (by running the code and clicking around)?

The implementation of features that already provided by command line interface should not be a problem. However, I do not understand how the search for package and change default repository function. Is it going to search the package from other website? Terry, is the pip_test.py need urgently? Because I am not familiar with the unittest library and it required me a few days to read its documentation. Maybe I can write one after the submission of proposal. But my first priority now is to change the design of the pip_gui.py file.

Here, I have one doubt regarding the get_data function that should the get_data function be a common function for different features for example : 

def _get_data(self, func_option):
        """
        A separate function for extracting data from the runpip() function.
        It is done in order to get this function tested using unittest module

        According to func_option, it returns the data extracted :

        Options:
        -------
        1. list : for listing all currently installed packages
        2. show <package name> : show details of installed packages
        3. search <keyword> : show formated search results
        4. install <package name> : get results while installing packages
        """

        splitted_options = func_option.split()

        if splitted_options[0] == 'list':
            return runpip(func_option)

        elif splitted_options[0] == 'show':
            return runpip(func_option)

        elif splitted_options[0] == 'search':
            return runpip(func_option)

        elif splitted_options[0] == 'install':
            return runpip(func_option)

I am not clear would this single function for retrieving data would be good for uniitest or different functions would be good for retrieving data.

Answering Eric:

'change default repository' would set a value that pip_gui would pass to subsequent install requests with the --index-url option.  On Windows, http://www.lfd.uci.edu/~gohlke/pythonlibs/ is essential and should be pre-listed as an option to select.

'search' (for package on pypi) is a pip command.  Try "pip search xyz".  On Windows, I would also want to be able to search the url above.

In the email, I said pip-test.py 'after applications'.

You may want to take a look a PyCharm's preferences dialog for inspiration.  I am attaching a screenshot.  I like the way they show installed and the latest available versions.

Upendra and Eric: get_list_data() should first parse the string into a list of lines with .splitlines.  At some point, I think the scrolled list should become a scrolled ttk.Treeview, which can have multiple columns.  Then get_line_data should parse each line into name and version.  Then a third column can be added to indicate that a newer version is available.  I wish I had that right now.  I have forgotten how to get the update-available info.

Alexander, the screenshot could not be more timely.  I was thinking of only putting something in the third column when an update is available, but that is a minor detail.

In any case, the point is that the  get_list_data should eventually prepare a package-list-specific list of triples that gets fed to show_list_data.

As I said on core-mentorship list, I decided that we should use Raymond's initial list for the feature list.  If anyone has any elaborations or additions, now is the time to post them.

Terry, now I have done two more mockup for the installed package tab which is referenced from your suggestion and belopolsky's suggestion. Which you do you prefer? About the http://www.lfd.uci.edu/~gohlke/pythonlibs/ repo that you suggested to be added inside, I have done some research about that and it seem like pip install --index-url can only search from something like this website https://pypi.python.org/simple/ format. So, I think maybe I have to parse the package from ttp://www.lfd.uci.edu/~gohlke/pythonlibs/, but without description. Is it ok?

One more thing, window should be able to install package with pip. So, why the need of http://www.lfd.uci.edu/~gohlke/pythonlibs/ ?

@Terry, I have tried to implement the treeview (as suggested by Alexander) and separate out the functions for retrieving data and displaying data. But, I have doubt on how to separate out the functions for getting data and displaying data. Further, I have changed the definition of 'runpip' function. I have used the subprocess module. Because of that few bugs are removed, but the speed of getting results from the pip command is slightly reduced.
Therefore, if you can get time to review my updated code, please tell me about possible improvements.

I had just one more idea after carefully going through all the options provided by pip. Other than the features suggested by Raymond, we should also provide option for installing using proxy settings.

Sometimes, configuring proxy can also be tricky while downloading. Can this be an additional feature? It can be easily implemented as pip provides --proxy option.

gohlke/pythonlibs/: Search will have to use a custom function.  If direct download from url by pip does not work, then we write a custom function to download to a temp file and pip install from local file.  (This is suggestion on site.)

runpip: It would be nice if import and main(...) could be made to work by reloading the module (to refresh the cache), but if not, subprocess should work as a backup.  Having 'run pip command' encapsulated makes it easy to switch without affecting the rest of the code.

Additional features: Raymond's list is not a firm cutoff.  I an not sure what a 'proxy' is in this context and have no sense of what will be useful, especially to beginners, rather than clutter.  But I am willing to be educated and persuaded.  And there are other people, including a second mentor for this project, who can give opinions.

@Terry, this is the code segment that I wrote to display the latest as you mention. Do give comment for improvement.

Sunday morning I posted "Adding a Pip GUI to IDLE and idlelib (GSOC project)" to the pydev list requesting that any objections to the current plan be raised and resolved soon, before final acceptance of a  student proposal and official initiation of work on it.

About ensurepip (point 1a on Raymond's list): ensurepip is a package in the stdlib.  Regardless of how we later run pip, its presence can be tested on startup by trying to import it. If not present, we should ask whether to install it or nor.  It can be installed either by running 'python -m ensurepip' in a subprocess or by doing what ensurepip.__main__ does:
  import ensurepip; ensurepip._main

From what I know after reading the ensurepip script, the ensurepip script is checking whether the pip and it requirement tools are installed right like get_pip.py that was mention https://pip.pypa.io/en/stable/installing/ ? So, we have to put it inside the gui script to ensure that the pip is installed. Otherwise, pass the "python -m ensurepip" to subprocess to install the package before start the gui of pip. Am I understand it correctly?

Is there any other uses of the ensurepip script?

I have one doubt about writing unittests for pip_gui. For writing the unittest what should I use as a test instance? For example, if we take particular pip package like : Flask

Now, if I have to test the 'get_data_show()' function in temp_pip_v3.py (using the assertXYZ functions), then I will use the output of 'pip show flask' as an example test case. But, it may be the case that Flask is not installed in others' machine. In this case the test would fail. Therefore, what should I use as a example test case?

Looking at the last two prototypes, an 'Installed packages' page would not need install, only update and remove.  A minor issue.  The PyCharm page with Install appears to contain part of an alphabetical listing of all packages on PyPI  (there are 10000s I believe).  This suggests that there is a PyPI interface to get such.  This would mostly be useful if someone know at least the first few letter of a name -- sort of like identifier autocompletion.

I am downloading and looking at the v3.py from each of you.

Ensurepip: for the present, I am willing to assume that is pip imports, it is ready to go.

try: import pip
except ImportError: <ask whether to install>

Testing: testing that runpip works will initially be done by running the app on our live systems.  For automated testing of the gui, runpip should be replaced with a mock that looks up a response string in a dictionary of argument-response pairs.  The response string should have the same format as pip responses, though they will usually be shorted.  For instance, the dummy 'machine' might have only two packages.  The description might be 'Description of package x' as that would be enough to test that a description is displayed when a line is double clicked.

In the last week, I have learned more about how to write functional tests for a GUI.  I will try to do one soon for IDLE.

Upendra: tem_pip_v3.py runs as I believe you intended from command line.  The details will need a scroll bar.

When run from Idle editor on my machine, it behaves strangely.  first, it restarts in a new shell window instead of the existing one.  This is wrong and I have not seen it before.  I have not yet figured out why.

Next, a blank console window appears before the tkinter gui window and disappears when the tkwindow appears.  Ditto. When an entry is double-click, a console window is opened and closed and no details are displayed.  Changing ["pip"] to ["pythonw", "-m", "pip"] fixes these issues.

The _get_data function is not needed for tests that I can think of.  Please remove debug prints and the 'are you sure you want to quit' box.

Eric: the vscroll is on a row above the Treeview.  Give explicit row and column for each grid call, and group together the grid calls for a given frame.

Eric: some of my comments on Upendra's file apply to yours also.

Terry, how do you run the script on idle? I try to run the script with idle -r "script name" and it was ok.

F5 from the editor, with a Shell window already present.

I try to open the script in editor mode and run the script. It restart shell and run the script. I upload the picture of it, is there any wrong with it?

It is wrong for Run Module to open a new shell window when there is a shell window already.  But I am not seeing this today with IDLE restarted, so for now, forget about it.

V4 is improved, but the list of installed packages is repeated and 2/3 repeated again, for a total of 2 2/3 appearances  - like 'abcabcab', where a, b, and c are packages.

The search button of search tab still not done yet, so it still cannot be used now

Upendra Kumar's GSOC pip-gui proposal has been accepted.  It is issue #27051 and progress can be followed there.  I leave this issue open, at least for now, for invoking the gui from IDLE.

Starting with June 20 msg268947 of #27051, Ned Deily raised the issue of adding something to the stdlib that depends on an external interface.  Nick Coughlin agreed that this is problematical.  Pipgui might have to be installed into site-packages from PyPI.

Once pipgui is installed on somewhere on the path, it does not matter where, as IDLE will use some variant of '<current-executable> -m pipgui'.  The issue is getting it installed *somewhere*.

Module mainmenu (Bindings in 3.5) uses the following code to conditionally add 'Turtle Demo' to the IDLE menu.

from importlib.util import find_spec
menudefs = ...
if find_spec('turtledemo'):
    menudefs[-1][1].append(('Turtle Demo', '<<open-turtle-demo>>'))

I believe the issue is that some Linux distributions either do or might make installing turtle-turtledemo a separate option from Tkinter and IDLE, so that IDLE might be installed but turtledemo not.  If turtledemo is not present, there is nothing for IDLE to do.

If pipgui is pip-installable, the same condition could be used , but in the menu event handler. When "if find_spec('pip') and not find_spec('pipgui')" is true, IDLE could offer to run 'python -m pip install pipgui' in a subprocess.

It is possible that some institution might block or remove a pip install.  IDLE should check for the presence of pip itself before adding the menu entry.

Nick, in answer to msg269259, see last two messages above.  The commit would be here and I would want your review before committing.

> always using a "--user" install if it doesn't detect an active virtual environment)

I will look up what --user does. You will have to educate me (preferably with code) about 'detect an active virtual environment'.  I have never used such.  Is running in a venv safer with respect to downloading 3rd party code?

Virtual environments don't provide any sandboxing, they just let you isolate different dependency sets from each other when switching between working on different applications.

If you're inside a venv, you'll see either:

    sys.prefix != sys.base_prefix (venv created by Py3 stdlib)

or:

    hasattr(sys, "real_prefix") (venv created by virtualenv)

In this case, you can assume the user has write permissions to the virtual environment and just invoke sys.executable with "-m pip install pipgui" as arguments.

If you're *not* in a virtual environment, you're running directly in the system Python, and the user may not have permission to install new packages for everyone (and even if they do, it's not necessarily a good idea). In that case, you want to pass "-m pip install --user pipgui", so the GUI components get installed in the user's home directory, rather than system wide.

Ned Deily and Nick Coughlin vetoed putting a pipgui in the CPython repository -- see #27051.  So, for the foreseeable future, there will not be anything to link to.

Note: I had to remove the open dependency because the tracker does not differentiate between closing something as fixed and closing it as unfixed.

In case this issue becomes active again, I'm listing my design implemented in Thonny IDE (http://thonny.org) -- see the attached png.

If you decide same design is suitable for IDLE, then I'm happy to create a version of the dialog without Thonny dependencies. Here's the current source: https://bitbucket.org/plas/thonny/src/master/thonny/plugins/pip_gui.py?at=master&fileviewer=file-view-default

For this idea to be revived, someone should write a PEP and open a new issue.