[Python-ideas] Looking for input to help with the pip situation

[Nick Coghlan]

On 12 November 2017 at 22:20, Paul Moore <p.f.moore at gmail.com> wrote:
> On 12 November 2017 at 06:19, Michel Desmoulin
> <desmoulinmichel at gmail.com> wrote:
>>> We still have to deal with the fact that basically every Unix
>>> environment is "advanced" in the above sense (the python2/python3
>>> split). I don't have a solution for that (other than "upgrade to
>>> Windows" ;-)).
>>
>> Provide the "py" command on linux and mac. And make it the default
>> recommended way in the documentation.
>
> +1 from me.

The current Python launcher is Window specific, and doesn't work on
POSIX systems. So the first barrier here is "Write a py command that
presents the same CLI on POSIX that the Python launcher does on
Windows".

The second problem is that even though we can add a "py" command to
the python.org Mac OS X installers and have that take effect for new
python.org downloads, there are a *lot* of people on Mac OS X and
Linux that don't actually obtain their pre-built Python from
python.org. While some of those would probably adapt and ship a new
command fairly quickly (the cross-platform commercial redistributors,
rolling release and 6-month cadence Linux distros, community
redistributors like pythonz, pyenv, and homebrew), other important
platforms wouldn't (most notably, LTS Linux distros).

The fact it wouldn't actually solve the bootstrapping problem due to
the update policies of various popular platforms then greatly reduces
the incentive to work on the first part of the problem (i.e. actually
creating a POSIX-compatible version of that CLI).

>> Well, not exactly. Do you do python -m venv, or py -x.x -m venv or
>> pythonx -m venv ? Wait, it's not installed by default on debian.
>
> Seriously? Debian don't provide venv in the standard Python install?
> That's just broken.

Yup. And RHEL/CentOS don't provide Python 3.x by default at all - you
need to grab it via other means.

>> Virtualenvs are a hard tool to use for beginners.
>
> Agreed. Genuine beginners just install Python, then use it. If they
> install extra packages, they want them to be available to all of their
> scripts.

Also agreed, but without them (or a functional equivalent, like `conda
env` or `pyenv`), it's incredibly hard to get an arbitrary user on an
arbitrary system to the point where all the following assumptions are
satisfied:

* the user is working at a command prompt (whether inside their IDE,
or in an actual system shell)
* the command `python` will run the desired version of Python
* the commands `pip install` and `python -m pip install` will be
essentially equivalent (aside from the differences when upgrading pip
itself on Windows) and install packages into the desired version of
Python
* any executables installed that way will be executable from that command prompt
* any Python import packages installed that way will be importable
from a Python shell started in that environment

(List of assumptions taken from
https://github.com/pypa/python-packaging-user-guide/issues/396)

Trying to drop any of those assumptions is problematic:

* non-command-shell learning environments vary even more than command shells do
* the `python` command has a much long history than any of the
alternatives (including both `py` and `python3`), and third party
guides reflect that
* the `pip install` option really is nicer looking than `python -m pip
install`, and it only has actual problems in the presence of multiple
Python versions and when upgrading pip itself on Windows (plus: lots
of third party guides recommend it, as do pypi.org project pages)
* if `pip install devtool` doesn't let you run `command-from-devtool`
in your command shell, that's thoroughly unhelpful
* if `pip install dist-package` doesn't let you run `import
library_from_dist_package` in your Python code, that's even less
helpful

It *would* be much nicer if a single user install of the Windows
python.org installer met these criteria by default, though - while the
`py` launcher is a good way of handling multiple versions (and nicely
fills the role of handling file associations for Python file
extensions), it isn't a particularly nice alternative to a properly
configured user PATH on a machine with only one Python installation.

>> A lot of people on this list have forgotten their early years it seems.
>
> Maybe. But the default beginner approach *does* have its problems, and
> guiding beginners to a better approach is a good idea.

We haven't forgotten our early years - we've just spent years (both
individually and collectively) working on the problem of helping
people get started with software development, and thus have a very
good idea as to what *doesn't* work, as well as what *does* work.

The latter list is currently fairly short:

* having a friend or colleague walk them through it
* "Install Parties", like those Django Girls runs (i.e. running a
pre-tutorial event, specifically focused on getting a working
environment set up)
* highly prescriptive learning environments, whether online ones (like
Grok Learning, trinket.io, PythonAnywhere, etc), or locally installed
ones (like PyCharm Educational Edition, the Anaconda distribution,
etc)

Without the kinds of constraints suggested in the last option, there
are too many potential starting points, and it isn't even possible to
ask potential learners to self-assess what their starting point
actually is, since it's a tech support problem where the first task is
"assess the current state of the user's system" (hence the first two
options).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia