[Distutils] Packaging and the dependency on distribute/setuptools

[Kelsey Hightower]

Re-posting for visibility:
http://groups.google.com/group/the-fellowship-of-the-packaging/browse_thread/thread/670085455d44eed5

While working on the new pysetup commands I ran into some issues when
trying to uninstall projects based on distribute/setuptools. The
current install method used in packaging is to "shell" out and call:

  # projects based on distutils

  python setup.py install --record=/path/to/record_file

  # projects based on setuptools

  python setup.py install --record=/path/to/record_file
--single-version-externally-managed"


This works and gets the project installed. However, this does not give
us PEP 376 compatibility and adds a dependency on
distribute/setuptools. Another side effect from the methods above, the
RECORD file does not end up in the right place. I am sure we can fix
this, but do we really want to?

To get everything working it seems we will have to do a custom
distribute/setuptools install similar to how pip does things.

https://github.com/pypa/pip/blob/master/pip/req.py#L540

Note, we do not have the above issue with packaging (setup.cfg) based projects.

At this point it seems we need to pick one of three options:

 1. Only support packaging based projects (setup.cfg)
 2. Only support packaging and distutils based projects, punt on
projects that require distribute/setuptools.
 3. Support all three, packaging, distutils, and distribute/setuptool
based projects.


Pros and Cons
=============

Option 1
--------
Only support packaging based projects(setup.cfg).

Pros

 * enforce the new standard, setup.cfg and static metadata.
 * clear project scope; one way forward
 * no dependencies on 3rd party modules (distribute)
 * chance to make a clean break; distutils is still in the stdlib and
pip supports Python 3

Cons

 * unable to install most projects day one; will have to defer to 3rd
party tools such as pip and distribute


Option 2
--------
Only support installing packaging and distutils based projects and
punt on projects that require distribute/setuptools.

Pros

 * can install more projects than option 1.
 * no dependencies on 3rd party modules (distribute)
 * promote the new standard with a transition for distutils based projects

Cons

 * still supports setup.py
 * causes confusion; can install some projects with a setup.py and not others
 * may prolong the move to setup.cfg and static metadata
 * miss our chance for a clean break

Option 3
--------
Support all three, packaging, distutils, and distribute/setuptools
based projects.

Pros

 * can install more projects than option 1 and option 2

Cons

 * WILL prolong the move to setup.cfg and static metadata. Most people
will continue to use what they know best.
 * miss our chance for a clean break


I am leaning toward Option 1 myself, as option 2 will only cause
confusion. Option 3 seems like going backward by requiring distribute
and will prolong the move to setup.cfg and static metadata. Going with
option 1 will require a lot of effort to get the community on board
and start converting to a valid setup.cfg, or providing support for
both, a valid setup.cfg and setup.py.

With packaging and pysetup being new tools we should keep them clean
and focused on the future. This is especially true when good
alternatives exist to provide a transition strategy for most projects.

Thoughts?