[Distutils] Distutils 2.7/3.1 and setuptools stack overflow

[P.J. Eby]

At 03:32 PM 7/19/2009 +0200, Martin v. Löwis wrote:
>Hi Phillip,
>
>I have investigated the problem of mutual recursion between setuptools
>and distutils a little. I read a message somewhere that you didn't
>understand the problem, so here is my analysis:
>
>1. build_py.data_files gets accessed, and is delayed-computed in
>    setuptools
>2. build_py tries to load the manifest, and goes to egg_info for that
>3. egg_info invokes add_defaults for the manifest
>4. manifest_maker.add_defaults invokes sdist.add_defaults
>5. in response to issue 2279, add_defaults now also adds build_py
>    data_files and package_data to the default files.
>
>As a work-around, I have now copied the 2.6 code of sdist.add_defaults
>into manifest_maker.sdist_add_defaults.

I don't understand.  Where did you do this?  In setuptools or distutils?


>In the long run, I think setuptools should revise its computation of
>data_files. Couldn't you simply use distutils' get_data_files()?

Setuptools supports an 'include_package_data' option that 
automatically includes any revision-controlled files found in package 
directories.  Distutils doesn't.  The somewhat-recursive aspect is 
that when an sdist is used instead of a checkout, the previous 
revision control info is not available, so setuptools must use the 
previously-computed list of included files in order to find out which 
files are "package data".

It's possible that this could be resolved in some other way, but IIUC 
Tarek has already implemented a setuptools patch to fix this, which 
has been applied to the "Distribute" fork of setuptools.  I am 
seriously considering simply blessing that fork *as* setuptools, at 
least with respect to the 0.6 maintenance branch, and turning over 
its stewardship to the Package Inquisition, or whatever they're 
calling themselves.  ;-)

("The Society For Packaging Things On Top Of Other Things" would 
probably be another good Monty Python-inspired name for the group.)