I'm trying to port 4Suite and Amara to setuptools. I thought 4Suite would be the hard part, but I have it basically functioning now. No such luck with Amara, though. 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, and even covered explicitly by the distutils and setuptools docs. If anyone else wants to try you can do so as follows: cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot login cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot get 4Suite -r EASYINSTALL-branch cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot get Amara This CVS is also accessible via viewcvs: http://cvs.4suite.org/viewcvs/ I'd appreciate any help. One last thing: is there an issue tracker for setuptools? -- 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/
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,
Actually, it's pretty *un*common, and it's not a good layout to use for many reasons, including non-importability during development, user confusion in understanding the layout, and inconvenience (i.e., a more natural layout wouldn't require setting package_dir at all). 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. Again, however, it *should* work, and as far as I can tell, it does.
cvs -d:pserver:anonymous@cvs.4suite.org:/var/local/cvsroot get Amara
I checked this out, and it builds an egg just fine for me under both 2.3 and 2.4. What problem are you having, exactly?
One last thing: is there an issue tracker for setuptools?
You're speaking to him now. :)
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/
At 04:31 PM 6/7/2006 -0600, Uche Ogbuji wrote:
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.
But that's not the same thing at all. The common layout in such a case is to have package_dir = {'':'src'} # or 'lib' and that is quite a different layout from what you're doing. I would be very curious to see what packages are doing as you are; at the moment I know of one that actually uses a {'foo':''} convention (which has similar problems), and I think I've seen one other besides yours that uses {'foo':'lib'}. But to my knowledge, the majority of 'src' and 'lib' dirs out there are following the {'':'src'} or {'':'lib'} convention in setup.py, not the {'foo':'lib'} one.
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.
Because there is no directory with the package's name, so simple browsing of the directory layout will not tell you what packages are in it. The src/ or lib/ prefix isn't the obstacle, it's the absence of disambiguating information.
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
I'd dispute that, as the distutils docs themselves *literally* describe the layout with packages in the setup.py directory as being the "most obvious". See: http://python.org/doc/2.4.1/dist/listing-packages.html The {'':'lib'} pattern is listed as "a different convention", and the {'foo':'lib'} option is listed last, as "another possible convention" -- hardly a stellar recommendation. :) Setuptools supports it, of course, because there *are* packages in the wild that use it. Nonetheless, I won't pass up an opportunity to encourage people to use the "most obvious" approach instead. :) I'm personally migrating away from the habit of using the {'':'src'} convention myself.
I'm just happy that it looks as if I'll be able to provide setuptools-enabled versions of 4Suite and Amara soonish.
I'm glad it's working for you. Please don't let any of this discourage you from reporting bugs; I'm just as happy when a reported bug can be considered fixed without actually making any code changes. ;-)
participants (2)
-
Phillip J. Eby -
Uche Ogbuji