You could teach them subprocess and os command injection safety from the start:<div><br></div><div>```python</div><div>import subprocess</div><div>import sys</div><div>cmd = [sys.executable, -m', 'pip', 'install', '-r', 'psfblessed-requirements.txt'])</div><div>retcode = subprocess.check_call(cmd)</div><div>assert retcode == 0</div><div>```</div><div><br></div><div>(Because shell=True is dangerous)<br><br>On Tuesday, October 31, 2017, Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/31/2017 12:21 PM, Ivan Levkivskyi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it was proposed several times before, but I just wanted to revive the idea that we could add<br>
a GUI interface to install/update packages from IDLE (maybe even with some package browser).<br>
</blockquote>
<br>
<a href="https://bugs.python.org/issue23551" target="_blank">https://bugs.python.org/issue2<wbr>3551</a>.  I agreed with and still agree with Raymond's opening message in Feb 2015:<br>
"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 <a href="http://python.org" target="_blank">python.org</a> and effortlessly install requests and other tools without users having to fire-up a terminal window and wrestle with the various parts."<br>
<br>
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()'.<br>
<br>
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 <a href="https://bugs.python.org/issue27051" target="_blank">https://bugs.python.org/issue2<wbr>7051</a>.  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.<br>
<br>
Looking back, I can see that I made two mistakes.<br>
<br>
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<br>
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.<br>
<br>
The second was not requiring an approved PEP before proceeding to actual coding.<br>
<br>
-- <br>
Terry Jan Reedy<br>
<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a>Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
</blockquote></div>