> On Nov 5, 2015, at 5:41 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > >> 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.
I think we can still use the ones we use now, although they might not support a zip file. Afaik they just execute a python script and I guess (hope) that they don't validate that and a zip file can be a "script" too. > 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. I'm my mind we wouldn't be throwing out wheels, we'd just build this zip instead. So our wheels would only contain this executable pip zip as a script (not console entry point) and pip would automatically wrap them with exe on Windows. > 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 :-) I think we could integrate with py on Windows somehow so that we use the same lookup semantics as py does. I don't know enough about Windows and py.exe to know what exactly those are. > > 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 :-( Yup :( > > 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] I'm also somewhat ambivalent by only because I'm just going to add an alias to restore "pip". > 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] I'm not sure if we'd need a different command to upgrade pip. In my head pip is still installed as a Python package. It'll just have non standard build steps. > 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] There wouldn't be anything preventing you from installing multiple versions of pip into an environment as we do today. It just wouldn't be mandatory. > > Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig