On 09.11.2015 02:13, Donald Stufft wrote:
On November 5, 2015 at 4:08:56 PM, Donald Stufft (don...@stufft.io) wrote:
Another possible option is to modify pip so that instead of installing into
site-packages we instead create an "executable zip file" which is a simple zip
file that has all of pip inside of it and a top level __main__.py. Python can
directly execute this as if it were installed. We would no longer have any
command except for ``pip`` (which is really this executable zip file). This
script would default to installing into ``python``, and you can direct it to
install into a different python using a (new) flag of ``-p`` or ``--python``
where you can specify either a full path or a command that we'll search $PATH
for.
I’ve implemented a proof of concept of this which can be found at
https://github.com/pypa/pip/pull/3234. It’s quick and dirty so probably will
break down in edge cases. I also know it currently doesn’t generate a
``pip.exe`` on Windows, so if someone runs it on Windows they’ll need to
execute it as ``python path/to/Scripts/pip``.
I’ve not tested trying to install it via wheel or even installing it via pip,
so you’ll want to check out the branch or download a tarball and run ``python
setup.py install`` (or you can run ``python setup.py build`` and just execute
``build/script-X.Y/pip``).
You might see errors if you don’t build it in a clean virtual environment.
That’s just because I haven’t bothered to try and isolate the build by default
yet.
From your comments on the PR:
> - We could possibly restore python -m pip and import pip with a
> sufficiently magical .pth file installed into site-packages.
Something like this should be done.
I like the idea to have just one pip installed, but I really wouldn't
like python -m pip to disappear.
Something I miss in all the discussions taking place here is the fact
that python -m pip is the officially documented way of invoking pip at
https://docs.python.org/3/installing/index.html#basic-usage and it is
not particularly helpful if that recommendation keeps changing back and
forth.
I know some people don't like the wordy invocation, but other people
(including me) use and teach it because it works reliably. Just because
a pip executable based invocation pattern looks better, I don't think it
justifies the change.
> - We could add some short hands inspired by py.exe with things like
> -2, -3, 3.4, etc that will translate to -ppython2, -ppython3,
> -ppython3.4, etc.
Sure, but this extra-effort will be needed just to re-enable something
that is already possible now via py -m pip.
Your .pth file idea makes me wonder whether an alternative solution
could be to share one regular pip installation between Python versions
that way.
Basically, ensurepip and get-pip.py could default to installing pip
(possibly as an executable zip file) into a separate folder and add a
.pth file to the sys.executable's site-packages. Later invocations of
ensurepip/get-pip.py through a different Python could then detect
presence of pip in its folder and simply add the .pth file to the
current site-packages.
This would solve the issue of having to manage multiple installations of
pip, but preserve all current usage patterns (invocation as executable,
python -m pip, import pip).
> - If we drop say, Python 2.6 and someone wants to install an older
> version, we might have to make it possible to override the name or
> something (python setup.py install --script-suffix 2.6?) to enable
> that particular special case to still work. This would only be
> needed really when altinstall'ing multiple Pythons into the same
> bin dir when one or more of those Pythons are not supported by the
> "main" version of pip you're using.
Yes, but such cases will occur more often as new Python versions are
released and you drop support for old ones. Effectively, any developer
who wants to support older versions of Python than the latest pip
supports will face the problem of explaining users what to do. So
something really convincing needs to be worked out here.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
