Richard Jones' Log: Open Source Dependency Hell
So one of the PyWeek 3 games uses Python 2.4, PyGame and PyOGRE.
- I'm running Ubuntu, so Python 2.4 is already installed and active
- "apt-get install python-pygame" installs a bunch of additional dependencies for me, no sweat
- PyOgre. No Ubuntu package. The tubes tell me that I can install it from its project site. So now I need to get psyco and "PyOgre (Media + PyOgre)". There's two "media files at the download site, "demo_media.zip" and "demo_media_1.2.0.zip" both with the same datestamp. The former has more downloads, so I go with that.
- "apt-get install python-psyco"
- In the PyOgre source, "python setup.py build". I realise it doesn't bundle OGRE. There's no README and no indication of this on the download site. Ho hum. "apt-cache search libogre" turns up "libogre5c2a". There's a vague reference to version "1.0.6-1.1ubuntu1" in the apt-cache "show" output. The current version on the Ogre3d website is "1.2.2p1" Not wanting to push my luck, I download the source from the Ogre3d website.
- The prerequsites list for Ogre3d is impressively long, so I go with only the required libs. I already have some installed.
- "apt-get install libzzip-dev"
- "apt-get install libmng-dev"
- "./configure --disable-cg && make install"...
- (during build) "apt-get install libxaw7-dev"
- (during build) "apt-get install libxxf86vm-dev"
- (during build) "apt-get install libdevil-dev"
- (during build) "apt-get install liblcms1-dev"
- The build then breaks saying "/usr/bin/install: cannot stat `.libs/libOgreMain.lai': No such file or directory" which was anticipated by the build instructions page. Followed instructions and "make install" completes.
- Back to pyogre.. "apt-get install swig"
- "python setup.py install" spits out a ton of messages about CEGUI configuration. I eventually figure that it's got an undocumented dependency on the optional Ogre3d dependency "cegui", so...
- "apt-get install libcegui-mk2-dev"
- Back to Ogre3d and "make distclean" (which actually breaks, so I remove the whole dir and unpack the tarball again) and "./configure --disable-cg" again.
- Back to pyogre.. "python setup.py install". It failed, spectacularly, starting with the line "gcc: : No such file or directory."
- Based on the advice here (though my error is different), I discover I have swig 1.3.27, so I download swig 1.3.29 and...
- "apt-get remove --purge swig"
- "./configure && make install" for swig
- Back to pyogre.. "python setup.py install". Based on the link above I re-run the build a few times, but unlike the results "hiasl" got, I do not end up with a successful build. I'm working on filing a bug report with the PyOgre project, but I'm currently waiting for the berlios system to email me my signup confirmation email...
Richard,
At least you are on a platform that Ogre builds on at all. I asked them about OS X support once and they expressed an extreme lack of interest in ever supporting OS X. The Mac has great 3D support, but none of the Python-enabled 3D libraries seem to want to support it.
Which might make sense, seeing how the Mac is a niche market. But every conference I attend seems to be 90% Macs (and 10% Linux), so you'd think *somebody* would want to capture the early adopter market.
To be fair, there has been some effort to port Panda3D to OS X, but I haven't yet gotten it working. Ah well, someday. Good luck with PyWeek!
If you knew a bit more about APT, you would have replaced step 6 to 13 with:
apt-get build-dep ogre
Even if you have to build from the source because the packaged version is outdated, you can easily get all build dependencies this way.
Thanks, Seo, I wasn't aware of that apt-get command.
I'm still waiting for my registration confirmation email from berlios - I assume it'll never arrive. I guess I have to try registering with a different name.
Cool site.
Hi Richard,
I've been trough some of these dependency hassles occasionally too (say with cx_Oracle, clearsilver (for trac)). I also noticed that the python ogre bindings are a fuzzy afair, and stayed that way for years.
Partly I think because of such incidents that ctypes is much better then swig, because it sidesteps a whole lot of mess in not needing to compile the wrapper itself.
You'd think with excelent distribution packaging systems like fink, apt or emerge such dependency hell would be a thing of the past. Surprisingly it still creeps up on you when a package didn't make it into such a repository.
the cheeseshop along with setuptools and cheesecake adresses I think some of the main issues. building your package, getting your package registered with the repository and checking it's quality to some degree.
Of course it doesn't solve dependency hell of compilation for packages that are not in the cheeseshop, however, a great unified, platform/distribution independent package installation system with similar functionality as the cheeseshop+setuptools+cheesecake for all software would surely be a lovely idea.