[Python-ideas] install pip packages from Python prompt

[Terry Reedy]

On 10/31/2017 10:41 AM, Nick Coghlan wrote:
> On 31 October 2017 at 05:57, Alex Walters 
> <tritium-list at sdamon.com 
> <mailto:tritium-list at sdamon.com>> wrote:
> 
>     > While I completely agree with this in principle, I think you
>     > overestimate the average beginner.

The average Python beginner may have a decade or more experience 
interacting with computers by voice, gestures, fingers on a screen, 
mouse clicks and movements, joystick controller clicks and movements, 
and single key presses.  This includes using a word processor.  They may 
or may not have consciously learned (or remember) anything about natural 
language grammar.  Python may well be their first experience with a 
formal language grammar and a picky interpreter.

>     Nope.  I totally get that they don’t know what a shell or command
>     prompt is.

A shell is a program in which users issue instructions one at a time as 
sentences in a formal language and wait for the response before issuing 
another.

>  THEY. NEED. TO. LEARN.

Yes.  But what shell should people who want to learn Python learn first?

Interactive python, which comes with a 'using' manual besides a tutorial 
and two reference manuals?

Or, on Windows, Command Prompt, which runs a sparsely documented unnamed 
language, has no tutorial, and has mostly been replaced by File Explorer?

One can just as well or better learn the idea of a REPL with formal 
language input from Python first.  Once one has learned interactive 
Python, learning to use other shells should be straightforward.  It 
should not be too hard to convey that a different language with a 
different syntax and different built-in commands requires a different 
interpreter.

> Hiding it is not a good idea for anyone.

Tell that to Microsoft, which in Win 10 removed command prompt and other 
'expert' tools from the regular start menu.

> We're not in the business of making judgements about who should and 
> shouldn't become Python programmers - we're in the business of making 
> sure that Python is accessible to as many people as possible by removing 
> irrelevant barriers to adoption, whether that's translating 
> documentation so folks can start learning with instructions in their 
> native language, or making it possible for them to defer learning the 
> idiosyncrasies of the Windows, Linux, and Mac OS X command line 
> environments.

My daughter learned Python and IDLE (from me) about 5 years before she 
had to learn about Command Prompt.  (In between, she had courses that 
used the Racket and Jave/Eclipse IDEs.)  The notion that she should have 
been forced to learn an inferior and useless (to her) shell first is to 
me absurd.

> On the latter front, the details of the development interfaces offered 
> by traditional desktop operating systems may *never* be relevant to the 
> new generation of folks coming through that are learning to program by 
> manipulating remote coding environments on tablets and other app-centric 
> devices, just as most developers nowadays are able to get by without 
> even learning C, let alone any flavour of assembly language. Our role in 
> this process isn't to create future generations that think and work in 
> exactly the same ways we do, it's to enable them to discover new ways of 
> working that build on top of whatever we create.

Amen. At least 99+% of my interaction with the hg repository and my 
clones thereof was through TortoiseHg and its Workbench gui.

> That means I now see a few potential RFEs from this thread:
> 
> 1. An import system feature that allows a running Python program to 
> report a timestamp (with the same granularity as pyc file timestamp 
> headers) for *when* the currently loaded modules were last modified. 
> This could be as simple as a new `__mtime__`  attribute in each module 
> to store that number.
> 2. A new importlib.util API to check for potentially out of date modules 
> in sys.modules (those where a freshly calculated module mtime doesn't 
> match the stored __mtime__ attribute)

> 3. Support in IDLE for Jupyter-style "!" commands

I believe that this was suggested on idle-dev and rejected by Guido as 
an expert feature, or perhaps as abbreviating and thereby encouraging an 
expert usage.  I will let him say what he thinks now.

I have considered adding 'Run OS Command' to the Run menu, but I mostly 
do not see the point for a Python shell or REPL.  If one knows what to 
type after '!', one can just as well click the appropriate icon and 
enter the command there.  Or use os.system or subprocess.  What am I 
missing?

> 4. Having IDLE call that importlib API and warn about any stale modules 
> after each command line operation

This seems heavy handed, usually unnecessary, but also inadequate.  One 
can now manipulate site-packages while running a Python shell in ways a 
shell will not know about.  One should then either start the shell 
manually or take the consequences.

As it is, IDLE restarts the user process each time one runs code from an 
editor.  Or one can explicitly restart the user process, without exiting 
IDLE, after installing or updating modules.

One objection to the latter has been that restarting, even on IDLE, 
clears more than one might want.  I am working on a separate proposal 
that would make it easier to regenerate a workspace.

*****

Hardly mentioned in this thread is that command line apps in general and 
pip in particular are not easily usable by many people.  One needs to 
use a particular app regularly or have an unusually good memory for 
fiddy details or a high tolerance for reading and ability to understand 
reading -h output.  That is why I think a pip gui would greatly help.

If nothing that directly goes in the stdlib, other than ensurepip, can 
depend on pip and its api, a helper module could be installed from pypi 
along with pip (by ensurepip!).

A pip wrapper, gui or not, could alleviate the following problem using 
pip in Windows.  There are up to date Windows binaries on Christopher 
Gohlke's site, https://www.lfd.uci.edu/~gohlke/pythonlibs/.  It 
currently has 32- and 64-bit builds for 2.7, 3.4, 3.5, and 3.6, as 
appropriate, for perhaps 450 packages.  At least some are source-only on 
pypi.  The site is not a pip package index, so the wheels must be 
downloaded first before being installed by pip.

As for the subject of this thread: I intended that the pip gui that you 
and Ned Deily vetoed should, unlike pip itself, be runnable from python 
with "import pipgui; pip.main()".  An import module can detect whether 
is it being run directly with Python or IDLE and, if sys.modules is 
modified, adjust its exit message or action accordingly.

The main problem with pip that I have seen on Stackoverflow is that 
people run pip on a command line with a binary different from the one 
that they run IDLE with, and then post 'X imports Y, IDLE does not'. 
The easiest way to ensure that something is installed for the binary 
running IDLE is for IDLE to run something with its sys.executable.

-- 
Terry Jan Reedy