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

[Michel Desmoulin]

General summary so far
#######################


This debate has been very civil so far and quite productive, so thanks
to everyone involved.

Several issues and solution proposals have been mentioned, so I will
make a summary here.

Issue 1: running Python is a different command different OS when several
versions are installed
==================================================================================================

Proposal A:
-----------

Suffix Python executable on Windows like on Unix, so that people will
type pythonX.X if they want a specify version.

Pros: easy and discoverable.

Cons: you need a lot of stuff in the system path.

Proposal B:
------------

Provide the "py" command on Unix, so that people will type "py -x.x"

Pros: no more issues with system path. Just add this command, and
register python installations to be listed by "py".

Cons: very few people know about "py", even on windows. This would need
lots of communication. Harder to change Mac and majors Linux distros
setup than just the next windows installer.


Issue 2: there is no one and only one obvious way to do venv / pip
===================================================================

Because pip and venv are tied to a Python version, there are numerous
ways to call them.

Just for pip, you have "pip", "py -x.x -m pip", "pythonx.x -m pip" and
"pipx".

Proposal A:
-----------

Decide on one form, and promote it everywhere.


Pros: simple.

Cons: long and tedious process, with a huge inertia before all 3rd party
to it. Would need a "PEP 8 for Python command". Requires "issue 1" to be
solved before.


Proposal B:
------------

Provide a pipenv-like behavior

pipenv is a tool created by the author of "requests" that automatically
"do the right thing" by default. The first time you install a package,
it creates a virtualenv for the current directory (but don't store it in
the current directory). It will then install all packages in there.
"pipenv shell" starts a shell in the virtualenv. Dependencies are
automatically dumped in a requirement files separating dev and prod.

Pros: bypass the multiple installers issue by prompting you what version
you wish the first time it creates a virtualenv. Solve the problem of
admin rights and system path.

Cons: lots of work. Either a new tool or breaking compat with pip. If
debian didn't install pip by default, this may not help.

Issue 3: pip and virtualenv are not available everywhere
===================================================================

Proposal A:
------------

Make a mock "pip" commands for when it's not installed. venv already
does that in some cases (see attachements), alhought it does give you
the wrong command so it should be fixed.

The gist of it: if the users try to run pip install while it's missing,
it prints a warning explaining it's not installed and the command you
can run to solve the problem plus a link to more information in the
documentation.

Pros: low friction to implement.

Cons: requires to put up a hook somewhere so that each linux distro can
input "the proper commands to use" for their system when they package
python. More a workaround than a solution.

Proposal B:
------------

Make pip and venv part of the standard and request debian that they
provide it.

Pros: straight forward.

Cons: holy war in the making.


.................


Can I have +1 and -1 from each of you on each point ?

Should I start a new thread for each of them ?


Favorite personnal combination
================================

1 - So far, I like "providing py on unix" better, but I think it's too
hard to do. So provide suffix on windows seems more achievable.

So +1 for having pythonX.X on windows.

2 - Decide on one form, and promote it everywhere is again the simplest
IMO. I love pipenv but the strings to pull to get something like this
means it probably would not happen.

If we stick to suffix for issue 1, this mean we can promote:

pythonX.X -m pip
pythonX.X -m venv

Everywhere. In the docs. In the tutorials. In teaching classes.

This will help a lot to remove all confusions and make the Python start
up experience way easier.

3 - getting angry debian devs is probably not wise. The "mock" pip/venv
command also plays very well with the 2 other solutions.

It means we can promote everywhere:

pythonX.X -m cmd

It will work most of the time. And when it doesn't, give clear
contextual steps on