On 5 November 2015 at 21:08, Donald Stufft <don...@stufft.io> wrote: > Thoughts?
The executable zip solution is in principle the best long-term solution. But the breakage is major, and it pretty much permanently cuts off any option to support use of pip as a library. That's probably OK, but we need to understand that fact. Further downsides to the executable zip approach: 1. We still need an "exe wrapper" on Windows. This can be as simple as prepending a stub exe to the zip, but we'd need either to maintain such a stub ourselves or find a supplier of one. 2. The Python 3.5 zipapp module includes support for a .pyz extension that is registered as a "zipped Python application". But as you noted, .exe is treated specially in certain places in Windows, and so there really is no alternative to a "pip.exe" command if we want the invocation to remain "pip". 3. On Windows, there is no guaranteed location that is on PATH. If we supply a "pip.exe" how will we ensure it's on the user's PATH? At the moment we take advantage of the Python installer (and virtualenv activate scripts) including the Python Scripts directory on PATH. If pip were an independent executable, we'd need people to manage PATH themselves. 4. Wouldn't the executable zip still be run with a specific Python, coded in the wrapper or shebang line? You say it'd install into "python" by default. But what about on Windows where the py launcher gets "the default Python" from its ini file, not from what's on PATH? And to use a different Python, you're potentially talking about "pip -p C:\Users\xxx\AppData\Local\Programs\Python\Python35\python.exe". Over my dead body :-) If I misunderstood, and your proposal is "python pip.zip", then there's still a problem as the *actual* usage would be "python C:\Whatever\Path\To\pip.zip" - which is far from user friendly. Overall I think that "python -m pip" is the best compromise. Users can write their own wrapper scripts, shell functions or aliases for common usage. But they probably won't in practice. So there is a lot of pain for users (not just command line use, every script that does subprocess.call(['pip', ...]) would need changing). Sadly, there's no really good solution :-( It seems to me that the main questions are: 1. Do we want the canonical invocation to remain "pip" or are we willing to break that? [I'm ambivalent on this, personally, but it's a significant compatibility break] 2. Do we mind if there's a different command needed to upgrade pip? [I don't, as long as pip supports *some* command to upgrade itself] 3. Do we want to move away from a pip per Python installation? [For me, it'd be somewhat convenient, but nonessential, and I suspect some people would have Python installations or virtualenvs where they want to have a *different* pip than the default one - so this change might actually be a regression for them] Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
