[Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

[Kevin Teague]

On Oct 6, 2009, at 10:36 AM, Hanno Schlichting wrote:

On Tue, Oct 6, 2009 at 7:00 PM, Bill Janssen <janssen at parc.com> wrote:
>> For me, it's more a matter of "OS X 10.6 already comes with setuptools;
>> how can I mitigate the impact of this buggy unmaintained package on the
>> systems I'm building to deploy on OS X?".  Adding distribute to the mix,
>> however good it is, doesn't help; I'm going to use a pure distutils
>> solution.  And I can't really install a bugfix release for the Python
>> frameworks in /System; only Apple can do that.
>
> I fear the canonical answer to this problem is: Don't use the system
> Python on Mac OS.
>
> It's not particular satisfactory, but as you noticed nobody besides
> Apple can fix problems in this Python install or update it to newer
> versions. Apple started to include quite a number of projects, like
> dateutil, Twisted, NumPy, zope.interface and setuptools to name a few.
> They will probably update those the next time in Mac OS 10.7 in one or
> two years. Even today the packages they ship are already outdated and
> miss bug fixes.
>
> So if you want to deploy to Mac OS, I fear the answer is to encourage
> people to install a good pristine Python version instead. Be that the
> official GUI installer, Macports, Fink or building your own Python
> from source. The installers for the Plone application include a full
> Python build for that reason.


I believe (but not 100% sure) that all of those projects (setuptools,
Twisted, zope.interface) got pulled into site-packages when Apple
began shipping iCal stuff. The existance of /usr/bin/easy_install and
setuptools is just a side-effect of Apple using an assortment of
Python projects to develop iCal. Perhaps we should have got one of
those projects that iCal depends upon to put some lightweight need-to-
import-it-but-don't-actually-use-it dependencies on VirtualEnv and
Buildout. Then those projects would have gotten pulled into Apple's
Python and we'd have the tools for easily isolating ourselves from
Apple's project's dependencies!

Alternatively, someone could work with Apple to get them to deploy
their Python apps in a self-contained manner, leaving an Apple Python
with a clean site-packages directory, all ready for people to go into
and start polluting in a non os-conflicting manner :P (well,
technically this directory is clean, it's just overshadowed on
sys.path by /System/Library/Frameworks/Python.framework/Versions/2.5/
Extras/lib/python/). They do ship their Ruby apps self-contained.
Heck, setuptools provides the same method of working with self-
contained library dependencies as Ruby Gems does, and it's not like
Apple has demonstrated any of the idiosyncratic "setuptools-aversions"
that exist elsewhere in the Python community. They do after all ship
with setuptools and ironically provide a /usr/bin/easy_install even
though setuptools also provides entry points as a way of cleanly
separating script installation from project installation. C'est la
vie!