[Distutils] The future of invoking pip

[Donald Stufft]

On November 5, 2015 at 5:06:07 PM, Barry Warsaw (barry at python.org) wrote:
> On Nov 05, 2015, at 04:08 PM, Donald Stufft wrote:
>  
> >One benefit of the third option is that we can remove the need to directly
> >copy the bundled libraries into the pip source code and we can install just
> >bundle it inside the built zip file.
>  
> This shouldn't be a problem from Debian's p.o.v. if we can adjust how packages
> end up in the zip file. If for example the zip contains wheels, and we finish
> the dirtbike (or similiar) project to rewheel distro packages, we'd use those
> pip-build-time generated wheels in the zip and be all good. Of course, we'd
> probably have to rebuild pip when we change any of those dependencies, but I
> think that's tractable.

My current proof of concept “forces” it to use something pip installed (though it could be pip installing a dirtbike generated wheel) but it really only does that because the most expedient way to make it work was to ``pip install foo —target TMPDIR`` and then recursively copy that into the zip file. There’s a number of possible ways it could work though, and if we did it, we’d want to make sure that it worked in a way that was friendly to downstream too.

>  
> I think the proposed solution is a better user experience that either of
> pipX.Y or `pythonX.Y -m pip`, so I'm glad you're experimenting with this
> approach.

In a total vacuum I think so too, the biggest worry I have is that we aren’t in a vacuum and we’re going to be breaking (at some point at least, whenever the deprecation period ends) some major interfaces (pipX, pipX.Y) and (python -m pip) and some minor ones (importing pip).

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA