[Distutils] PEP439 and backward compat / easy_install / distlib

[Nick Coghlan]

On Sun, Mar 24, 2013 at 2:48 AM, holger krekel <holger at merlinux.eu> wrote:
> Hi Richard, all,
>
> two first notes on PEP439.

PEP 439 is just one small piece of a much larger puzzle, and the
entire puzzle won't be explained in this PEP. I realise this makes it
hard to evaluate in isolation, but the beta freeze for 3.4 is still
several months away and all the other pieces will be in place well
before then. Please be patient with us as we get all the pieces
documented and published over the coming weeks.

However, I do have some comments on your specific questions:

- while easy_install has provided good service for many years, it is
not a viable choice as the officially supported installer. It's
default behaviour is completely broken from a system administrator's
point of view, as using it to install things has side effects on every
Python application run on that system, and the lack of uninstall
support is not acceptable either. By contrast, pip has tried from the
beginning to accommodate the interests of system administrators *as
well as* developers, making it much easier to justify its being
blessed as the official installer. The approach taken to this over the
coming months will be to identify the reasons that people still use
easy_install for some tasks and add support for them to pip.

- eggs are too closely associated with easy_install to easily
rehabilitate their image with system administrators and platform
packagers, and also lack some of the necessary metadata to
interoperate correctly with platform packaging tools. The new wheel
format builds on a combination of eggs and the sysconfig installation
path concept to create a format that can be more readily mapped to FHS
compliant platform specific packages. Wheel also introduces the
enhanced "compatibility tag" format for filenames, which covers more
details of the Python and platform dependencies of the built
distribution.

- We could potentially provide server side support for automatically
generating wheels from eggs uploaded to PyPI, but that would be a
question for catalog-sig (since it is purely about PyPI's feature set
and behaviour, and independent of the packaging and distribution
standards themselves)

- metadata 2.0 specifically includes the "Setup-Requires-Dist" field
so that projects that require additional dependencies when building
from source will be correctly supported by pip and other metadata 2.0
compliant installers. This will be supported transparently for users,
so long as they update to metadata 2.0 compliant versions of their
build tools (setuptools/distribute, distutils2, d2to1, hashdist, etc).
Python 3.4 will also continue to provide distutils, so that metadata
1.0 and 1.1 packages generated with older versions of distutils will
continue to work correctly.

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia