On Sun, Mar 24, 2013 at 8:49 PM, Richard Jones <richardjo...@optushome.com.au> wrote: > 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 :-)
I am not adding setuptools to the standard library, which is effectively what we're doing for anything installed automatically via the pip bootstrap script. Things have moved on since Guido approved setuptools for inclusion in 2.5, and I'm not adding an entire legacy module only to immediately deprecate it in favour of the updated toolchains. That means anyone assuming setuptools will be present as part of all Python installations is just plain wrong, both now and in the future. Therefore, any installation of setuptools on a system *must* be requested explicitly, either directly (via "pip install setuptools") or indirectly (by installing something that explicitly depends on it through a setuptools requirements file, Setup-Requires-Dist or Requires-Dist). The *only* case this approach doesn't immediately cover is a project that: 1. Doesn't publish a pre-built wheel for the current platform (or egg, assuming pip gains support for those, perhaps by implicitly converting them to wheels) 2. Doesn't publish 2.0 metadata with "Setup-Requires-Dist: setuptools" 3. imports setuptools in its setup.py file This can be handled in pip, by using the AST module to scan for setuptools imports in setup.py (or else by checking for a setuptools related ImportError after trying to run it). Yes, it's a hack, but I am *not* going to approve a PEP that further entrenches something even its creator would like to see waved off into the sunset, giving thanks for its good service :) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
