[Distutils] PEP439 and backward compat / easy_install / distlib

[Daniel Holth]

Wheels are very similar to eggs. The initial wheel implementation
converts *every* newly built wheel from .egg-info to .dist-info since
setuptools doesn't know how to generate the new metadata. I think you
will find the conversion to be reliable, though it can't download the
eggs for you right now.

The hypothetical no-setuptools pip will probably add an implicit
setuptools dependency to every sdist, installing it automatically as
an additional dependency, until we invent a way for sdists to say that
they don't need setuptools. "pip install" always forces its setup.py
subprocesses to use setuptools.


On Sun, Mar 24, 2013 at 11:49 PM, Richard Jones
<richardjones at optushome.com.au> wrote:
> 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
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig