[Distutils] PEP439 and backward compat / easy_install / distlib

[Richard Jones]

On 25 March 2013 14:11, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

Because of the reason I stated later; it's a second hurdle that users
have to get over before installing the actual thing they wish to
install. All packages that depend on setuptools must include the
instructions "but first install setuptools."


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

This would indeed be simpler.


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

Yep.


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

Hm. I'm not sure I get this point. The intention in the PEP is to
install the pip implementation from a wheel, not sdist. So maybe I'm
missing the relevance of sdist being mentioned here.


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

OK. So I'm -1 on that ;-)


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

I think we have too much legacy to support here. Sure it'd be nice if
everyone just switched over to PEP 426 style overnight, but it ain't
gonna happen. The intent of the automatic setuptools installation is
to mirror the *current* situation which people rely on: when pip's
installed you also have setuptools (/distribute) installed. Packages
may then depend on setuptools in their setup.py with fair confidence
that it'll be there. Having this PEP support pip without setuptools
will make packaging more complex which is antithetical my goal with
the PEP. I can't support a PEP that will make things more complex :-)


     Richard