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. > 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 <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. > 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
