You could teach them subprocess and os command injection safety from the start:
```python import subprocess import sys cmd = [sys.executable, -m', 'pip', 'install', '-r', 'psfblessed-requirements.txt']) retcode = subprocess.check_call(cmd) assert retcode == 0 ``` (Because shell=True is dangerous) On Tuesday, October 31, 2017, Terry Reedy <[email protected]> wrote: > 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 > > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
