[Distutils] Expectations on how pip needs to change for Python 3.4

[Brett Cannon]

On Sat, Jul 13, 2013 at 11:15 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 13 July 2013 16:03, Donald Stufft <donald at stufft.io> wrote:
>
>>
>> > 1. Install to user-packages by default.
>>
>> Do people really want this? I hadn't seen it (other than if pip was
>> installed to user by default). I think it's a bad idea to switch this on
>> people. I doubt the user-packages is going to be in people's default PATH
>> so they'll easily get into cases where things are installed but they don't
>> know where it was installed too.
>>
>
> I believe Nick wants to make user-packages the default. I know at least
> some of the pip maintainers (yourself included) have reservations.
> Personally, I've never used user-packages, so I don't know what issues
> might arise. But I hope to try it out sometime when I get the chance, just
> to get some specific information.
>

I would assume the executable script was installed next to the python
binary but the library parts went into user-packages. That way -m would
work for all binaries of the same version.


>
>
>> > 2. Not depend on setuptools (??? - Nick's "inversion" idea)
>>
>> I wanted to do this anyways. It will still "depend" on it, but it will
>> just bundle setuptools itself like its other dependencies. For pip
>> dependencies are an implementation detail not an actual thing it can/should
>> have.
>>
>
> Bundling is not the same as Nick's suggestion. I personally have no
> problem with bundling, but pip install with a bundled setuptools might not
> work because the setup subprocess won't see the bundled setuptools when it
> imports it in setup.py. But either way, it's doable, I just want to know if
> it's on the critical path...
>
>
>> > 3. Possibly change the wrapper command name from pip to pip3 on Unix.
>>
>> Not sure on this. Ideally i'd want the commands to be pipX.Y, pipX, and
>> pip all available and not install the less specific ones if they already
>> exist but that might be too hard?
>>
>
Could we just start to move away from an executable script and start
promoting rather aggressively -m instead? It truly solves this problem and
since the results are tied to the Python executable used (i.e. where
something gets installed) it disambiguates what Python binary pip is going
to work with (something I have trouble with thanks to Python 2 and 3 both
being installed and each with their own pip installation). I realize older
Python versions can't do this (I believe 2.6 and older can't for packages)
but at least in the situation we are discussing here of bundling pip it's
not an issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/3a262a90/attachment.html>