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

[Noah Kantrowitz]

On Jul 13, 2013, at 9:59 AM, Brett Cannon wrote:

> 
> 
> 
> 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.

No, this is not how any user ever will expect unix programs to work. I know that python -m is very cute, and I use it myself for some debug and helper functionality at times, but it can never replace normal scripts. This is a user experience expectation, and we will have to meet it.

--Noah


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/609d52ac/attachment.pgp>