[Distutils] Bug in setuptools-0.6a11-py2.4 ?

[Uche Ogbuji]

Phillip J. Eby wrote:
> At 12:35 PM 6/7/2006 -0600, Uche Ogbuji wrote:
>> I can't get setuptools to handle the fact that Amara has all its code in
>> a subdir named lib, such that it used to work fine in plain distutils as
>> follows:
>>
>> setup(package_dir = {'amara': 'lib'}, packages = ['amara'],...)
>>
>> This same invocation with setuptools does not give an error message, but
>>  no packages are found or processed.
>>
>> I also tried:
>>
>> setup(package_dir = {'amara': 'lib'},
>>       packages = find_packages(),
>>
>> setup(package_dir = {'amara': 'lib'},
>>       packages = find_packages('lib'),
>>
>> setup(package_dir = {'amara': 'lib'},
>>       packages = find_packages(),
>>       packages = ['amara'],
>>
>> and many other desperate attempts, with no luck.
>>
>> It feels to me like a bug in setuptools with such a layout, but I'm
>> really surprised, because it's so common,

I think this issue report turned out to be a bogon, as I'll elaborate
below, so I hate to launch into a debate that should never have been
inspired in the first place, but some of the things you said puzzle me.

> Actually, it's pretty *un*common, and it's not a good layout to use for
> many reasons,

Based on the projects I see in my Python src directory, it is indeed
common.  Sometime the code dir is called "lib", sometimes "src", and
occasionally something else.  I guess we just seem to use a disjoint set
of Python packages.

> including non-importability during development,

I don't understand why that's bad.  setuptools seems to go out of its
way to make it so you can do this.  That's fine with me, but I don't see
it as an important feature by any means.

> user confusion in understanding the layout,

Again I don't see your point.  Why do you think a user would be
confused?  This is the first I've heard such a claim in a long time
managing project layouts.

Personally, I don't have an objection to any layout as long as there's a
README to explain it.

> and inconvenience (i.e., a more
> natural layout wouldn't require setting package_dir at all).

Why is adding one dict to the setup call an inconvenience?  As I said,
it's mentioned right in the distutils manual.

> Merits of the layout aside, it should nonetheless work properly with
> setuptools, and I actually didn't have any problems with it.  (see
> further below)
> 
> 
>>  and even covered explicitly by
>> the distutils and setuptools docs.
> 
> Actually, setuptools only mentions creating a *parent* package, e.g.
> package_dir={'':'lib'}, where the 'amara' package directory would then
> be a subdirectory of lib.

That's true.  But to me the fact that it's a prominent pattern in base
distutils docs is enough, especially since setuptools bills itself as a
drop-in replacement.

> Again, however, it *should* work, and as far as I can tell, it does.

And here I think you have me.  I was working within my CVS local
repository, where I do all my development play.  After your success
report, I checked out clean versions of everything to a new directory,
and all went well.  I can only imagine that something in my previous
working directories was confusing things.

I should have done this before posting to the list, but I thought I'd
received corroboration of the problem from someone who would have
checked out a fresh repository already.  Sorry for all the noise, and
thanks for trying things out.

I'm just happy that it looks as if I'll be able to provide
setuptools-enabled versions of 4Suite and Amara soonish.


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/