<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 14 November 2017 at 16:47, Michel Desmoulin <span dir="ltr"><<a href="mailto:desmoulinmichel@gmail.com" target="_blank">desmoulinmichel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">General summary so far<br>
#######################<br>
<br>
<br>
This debate has been very civil so far and quite productive, so thanks<br>
to everyone involved.<br>
<br>
Several issues and solution proposals have been mentioned, so I will<br>
make a summary here.<br>
<br>
Issue 1: running Python is a different command different OS when several<br>
versions are installed<br>
==============================<wbr>==============================<wbr>==============================<wbr>========<br>
<br>
Proposal A:<br>
-----------<br>
<br>
Suffix Python executable on Windows like on Unix, so that people will<br>
type pythonX.X if they want a specify version.<br>
<br>
Pros: easy and discoverable.<br>
<br>
Cons: you need a lot of stuff in the system path.<br></blockquote><div><br></div><div>Con: we hope to have the problem resolved on the Linux distro side such that "python" typically means "python" by the time community support for Python 2 ends in 2020. Since Windows has gone the better part of two decades without version Python commands, adding them because we're impatient with the pace of change at the Linux distro level doesn't really make sense (especially when Linux holds such a small fraction of the non-phone client device market).</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Proposal B:<br>
------------<br>
<br>
Provide the "py" command on Unix, so that people will type "py -x.x"<br>
<br>
Pros: no more issues with system path. Just add this command, and<br>
register python installations to be listed by "py".<br>
<br>
Cons: very few people know about "py", even on windows. This would need<br>
lots of communication. Harder to change Mac and majors Linux distros<br>
setup than just the next windows installer.<br></blockquote><div><br></div><div>Proposal C:</div><div><br></div><div>Make sure 'python' just works on a default Window user install, and treat any system where that doesn't work by default as a special case that needs troubleshooting.</div><div><br></div><div>Pro: a solid troubleshooting guide will be useful regardless</div><div><br></div><div>Con: mainstream Linux distros will still be a consistent exception for at least the next couple of years (and probably longer for the LTS variants)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Issue 2: there is no one and only one obvious way to do venv / pip<br>
==============================<wbr>==============================<wbr>=======<br>
<br>
Because pip and venv are tied to a Python version, there are numerous<br>
ways to call them.<br>
<br>
Just for pip, you have "pip", "py -x.x -m pip", "pythonx.x -m pip" and<br>
"pipx".<br>
<br>
Proposal A:<br>
-----------<br>
<br>
Decide on one form, and promote it everywhere.<br>
<br>
<br>
Pros: simple.<br>
<br>
Cons: long and tedious process, with a huge inertia before all 3rd party<br>
to it. Would need a "PEP 8 for Python command". Requires "issue 1" to be<br>
solved before.<br></blockquote><div><br></div><div>This downside doesn't apply as long as the form we standardise on is "pip install module".</div><div><br></div><div>That already works in a lot of contexts, and the cases where it doesn't work are typically ones where "python -m pip" may also be a problem.</div><div><br></div><div>Given a solid troubleshooting guide for issue 1, we may also be able to add some implicit checks to pip that provide alerts for problematic configurations, like checking:</div><div><br></div><div> >>> user_scheme = "posix_user" # or "nt_user" or "osx_framework_user"<br> >>> sysconfig.get_path("scripts", scheme="posix_user") in os.getenv("PATH").split(os.pathsep)<br> True<br></div><div><br></div><div>The latter check returning false is a sign that the `PATH` configuration might be a problem.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Proposal B:<br>
------------<br>
<br>
Provide a pipenv-like behavior<br>
<br>
pipenv is a tool created by the author of "requests" that automatically<br>
"do the right thing" by default. The first time you install a package,<br>
it creates a virtualenv for the current directory (but don't store it in<br>
the current directory). It will then install all packages in there.<br>
"pipenv shell" starts a shell in the virtualenv. Dependencies are<br>
automatically dumped in a requirement files separating dev and prod.<br>
<br>
Pros: bypass the multiple installers issue by prompting you what version<br>
you wish the first time it creates a virtualenv. Solve the problem of<br>
admin rights and system path.<br>
<br>
Cons: lots of work. Either a new tool or breaking compat with pip. If<br>
debian didn't install pip by default, this may not help.<br></blockquote><div><br></div><div>This is essentially the path that conda takes, and it works well for folks that are willing to adopt conda's specific approach to managing your Python runtimes.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Issue 3: pip and virtualenv are not available everywhere<br>
==============================<wbr>==============================<wbr>=======<br>
<br>
Proposal B:<br>
------------<br>
<br>
Make pip and venv part of the standard and request debian that they<br>
provide it.<br>
<br>
Pros: straight forward.<br>
<br>
Cons: holy war in the making.<br></blockquote><div><br></div><div>I don't think it's *that* bad. Debian does have support for weak dependencies, so the resolution here may be as simple as asking Matthias to add a Recommends from python3 to python3-venv so that ensurepip is present by default on typical workstation configurations, but can still be easily omitted from server configurations. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Favorite personnal combination<br>
==============================<wbr>==<br>
<br>
1 - So far, I like "providing py on unix" better, but I think it's too<br>
hard to do. So provide suffix on windows seems more achievable.<br>
<br>
So +1 for having pythonX.X on windows.<br></blockquote><div><br></div><div>I think this is actually similar to the situation with 'py' on *nix systems: with Windows having never had these before, adding and promoting them would be at best ineffective, and at worst outright confusing (especially if "python" starts meaning Python 3 by default on Linux as well within the next few years).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2 - Decide on one form, and promote it everywhere is again the simplest<br>
IMO. I love pipenv but the strings to pull to get something like this<br>
means it probably would not happen.<br></blockquote><div><br></div><div>We've been evaluating a potential pipenv tutorial for the Python Packaging User Guide, and while we're likely going to add it soon, it will be as a new "application dependency management" tutorial alongside the existing ones, rather than as a direct replacement for the pip-based "package installation" tutorial: <a href="https://github.com/pypa/python-packaging-user-guide/issues/394#issuecomment-343343760">https://github.com/pypa/python-packaging-user-guide/issues/394#issuecomment-343343760</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If we stick to suffix for issue 1, this mean we can promote:<br>
<br>
pythonX.X -m pip<br>
pythonX.X -m venv<br>
<br>
Everywhere. In the docs. In the tutorials. In teaching classes.<br>
<br>
This will help a lot to remove all confusions and make the Python start<br>
up experience way easier.<br></blockquote><div><br></div><div>Except it won't, because now you can't seamlessly update your class instructions to new versions of Python - you'll have to go through and change all the "X.Y" references to refer to the right version. Writing cross-platform scripts will also get even harder, as you wouldn't be able to say "I just need a version of Python, I don't really care which one" any more.</div><div><br></div><div>Python feature releases are already disruptive enough due to filesystem layout changes and file format changes - we don't need to make them worse by encouraging people to embed the exact target version in their documentation and helper scripts.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3 - getting angry debian devs is probably not wise. The "mock" pip/venv<br>
command also plays very well with the 2 other solutions.<br></blockquote><div><br></div><div>While I was a bit snarky about "python -m venv" being broken by default earlier in the thread, *please* don't take that as meaning that we can't collaborate constructively with the Debian folks. We can, and do, but the friction between language level package management and system level package management is one with a *long* history that we're all working towards resolving together (See [1] & [2] for write-ups of a couple of <a href="http://linux.conf.au">linux.conf.au</a> talks I've given about the problem), as is the question of how best to handle the `/usr/bin/python` symlink.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It means we can promote everywhere:<br>
<br>
pythonX.X -m cmd<br>
<br>
It will work most of the time.</blockquote><div><br></div><div>The combination of:</div><div><br></div><div><div> pip install package<br></div> python -m venv</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">already works in most cases, *except* apparently the critical one of "New Python user on Windows downloads the <a href="http://python.org">python.org</a> installer and clicks through all the buttons without changing any settings".</div><div class="gmail_quote"><br></div><div class="gmail_quote">So I think the main near term step forward would be to convince Steve Dower (as the Windows installer maintainer) to change that default behaviour yet again for 3.7, and then work towards coming up with a solid environment troubleshooting guide to include on <a href="http://packaging.python.org">packaging.python.org</a>.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">Nick.<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://lwn.net/Articles/580399/">https://lwn.net/Articles/580399/</a><br></div><div class="gmail_extra">[2] <a href="https://lwn.net/Articles/711906/">https://lwn.net/Articles/711906/</a></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia</div>
</div></div>