[Distutils] Where is the setuptools source repository?

[Tarek Ziadé]

>>> (Btw, 'package_data' will cause things to get included at install time,
>>> but
>>> it does not put them into sdist.  You'll need to use MANIFEST.in or a
>>> revision-control plugin to get data files included in an sdist.)
>>
>> At distutils level, that's not true anymore with the current distutils
>> trunk though, which includes
>> package_data files without having to put them in the MANIFEST template
>
>
> Interesting.  I didn't realize that this changed.  This works at least as
> far back as Python 2.4, so if it changed, it changed some time ago.  Of
> course, the documentation:
>
>  http://docs.python.org/distutils/setupscript.html#installing-package-data
>
> indicates it should work. It also indicates that this option is new in
> Python 2.4.

I can't find in the svn logs such changes. Are we talking about the same issue ?
e.g. being forced to define package_data files in the MANIFEST.in
template to have them included
by sdist ?

What happened is that someone added an issue complaining that defined
package_data were
not installed, *unless* defined in the MANIFEST.in,

so I have worked in sdist to include them when the command is called
(in add_defaults), so it'll work
for Python 2.7.

btw, that breaks setuptools because its sdist command patches
disutils's sdist to provide a function that scans
VCS/DVCS directories and dies in a recursive loop.

I've provided a patch in setuptools bug tracker to avoid this. The
patch keeps the 'old' behavior so setuptools can
still work as expected when scanning vcs dirs. But it's a hack.

Notice that my plan is to backport distutils 2.7 when Python 2.7/3.2
is out, for python >= 2.5 and to provide
a new compatibility branch for setuptools at the same time for people
that uses it (unless the project evolves before
we reach that date). I am wondering though if it's not a good idea to
start that branch now, so it changes
while distutils changes, and is ready the very day 2.7/3.2 are out.