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 <richardjo...@optushome.com.au> wrote: > On 25 March 2013 14:11, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 3/24/13, Richard Jones <richardjo...@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 <ncogh...@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 <hol...@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@python.org > http://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
