[Distutils] PEP439 and backward compat / easy_install / distlib

Nick Coghlan ncoghlan at gmail.com
Mon Mar 25 04:11:30 CET 2013

On 3/24/13, Richard Jones <richardjones at optushome.com.au> wrote:
> This is a valid concern. Obviously "pip install easy_install" is not a
> solution - especially since the general intention is to deprecate
> easy_install eventually (as explained in Nick's response). I did not
> discuss eggs with the pip developers while at PyCon which is quite
> unfortunate. I would appreciate any insights from those devs on the
> matter.

Why is "pip install setuptools" not a solution? It's easier than
getting setuptools installed is today.

> It may be that wheel convert can solve this issue for some eggs.
> Unless it can be fully automated it's not going to solve it for all.

The simplest solution is likely for pip to gain support for installing
from eggs, despite their known issues.

>> setuptools and distlib:  Even if Python3.4+ had a mature distlib
>> providing minimal setuptools functionality, how would it work for the
>> typical "python setup.py install" which is invoked by pip?  Often those
>> setup.py scripts depend on a setuptools package.
> This is not the bootstrap's problem (and hence not the PEP's) since
> the bootstrap exists *solely* to install the pip implementation. If
> that's not clear enough in the PEP then I can attempt to make it
> clearer.

Right, in every PEP we should probably make the builder vs installer
distinction clear, and be explicit that the PEP only covers the
installer side.

"install from sdist" unfortunately blurs that boundary, and we may
need an egregious hack like doing a substring search for "import
setuptools" in setup.py when installing from an sdist with metadata
1.x in PKG-INFO.

One of my key long term goals is to eventually allow system
administrators to control whether or not a build system ends up on
their production servers. At the moment that's not possible (and it
likely won't be for 3.4 either), but that's where I would like us to
get to somewhere along the line.

> On 25 March 2013 03:04, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> - once we can bootstrap pip, then bootstrapping easy_install if it
>> still needed for some edge cases will be as easy as installing
>> anything else that is either pure Python or publishes an appropriate
>> wheel for the platform: "pip install setuptools"
> I'm -0 on the idea of also including an easy_install bootstrap in the
> Python install, since I personally would prefer not to require users
> to have to deal with two install tools which behave slightly
> differently.

I only meant "pip install setuptools && easy_install other_project",
not a separate bootstrap command.

> On 25 March 2013 07:21, holger krekel <holger at merlinux.eu> wrote:
>> If you have to explain pip-bootstrapping, then
>> install setuptools, then the actual package, it's not much of an
>> improvement anymore.
> The point of this PEP is to remove the first "explain pip
> bootstrapping" step from this equation.
> I had thrown around the idea of the pip bootstrap installing both pip
> implementation *and* setuptools. At the time my justification was that
> pip depended on it. The pip devs have indicated that they could remove
> the setuptools dependency when distlib and wheel support are in the
> Python standard library.
> ISTM however that there is still quite a good justification for
> installing setuptools during the bootstrapping, for the reasons you
> state.

I can make this part simple: I won't accept a PEP that proposes
automatically installing setuptools even if you never install a
package from source, and never install anything that needs
pkg_resources :)

We will make it easy for people to install setuptools if they need it.
Projects built with newer versions of setuptools will have
"Setup-Requires-Dist: setuptools" and "Requires-Dist: setuptools"
configured appropriately, while pip will also correctly pick up a
runtime dependency identifies in a requires.txt file.

But the idea is to eventually deprecate
setuptools/pkg_resources/easy_install as components that get deployed
to production systems, and leave setuptools as a build system only.
It's going to take us a while to get there (especially since we still
need a path hook to replace pkg_resource.requires), but even when we
do, they will always remain only a "pip install" away for projects
that still need them.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list