Stripped pkg_resources out of OpenGLContext and PyVRML97
Written by
on
in
Snaking.
Long story short, I'm cutting my losses and stripping all of the pkg_resources stuff out of OpenGLContext and PyVRML97, that is, all of the entry points, dependency declarations etceteras. I'll likely also get around to eliminating the setuptools dependency at some point (i.e. switching to raw disutils), but I haven't enough time to do that today. I've switched the plugins to using the trivial plugin mechanism provided by PyOpenGL and eliminated the frivolous use of entry points to register the accelerator modules for PyVRML97.
I still think we need a robust, data-driven mechanism for installing and resolving dependencies between Python packages, but I have so little time for Open Source these days I need to focus on just getting my little piece out the door with reliable, if somewhat primitive tools, rather than spending my time trying to make it all work with the latest-and-greatest cutting-edge tools.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Anders on 10/19/2008 6:25 a.m. #
Isn't PyOpenGL packaged pretty well by the major linux distributions? It certainly is only an apt-get away on Ubuntu.
Thanks,
Anders
Mike Fletcher on 10/19/2008 6:55 p.m. #
Yup, it's reasonably well supported on Linux, but OS-X and Win32 users wind up using SetupTools most of the time.
PJ Eby on 10/20/2008 8:08 a.m. #
So, where'd you report the bugs? I don't see them on the list or in the tracker.
Mike Fletcher on 10/20/2008 9 a.m. #
The TurboGears problem with the c9 setuptools was a known bug (not to me, obviously). It was "fixed" in TG 1.0.6 to work around whatever setuptools change triggered the bug. That version of TG was, apparently non-functional. Advice in the post I read was to use SVN head of TG... realistically, downgrading setuptools was much easier and allowed me to continue using the same TG 1.0.5 as the project was using.
On reflecting, "setuptools bug" is the wrong way to describe it; maybe "setuptools backwards incompatibility" would have been a better description? Heck, I don't even know whether it was a mis-use of setuptools in 1.0.5 or just a different operating mode where c9 did something "correct" to fix a c8 bug TG was relying on. I just read the article and fixed the problem so I could get the client's work started.
In theory TG 1.0.5 could have a declaration that it requires a setuptools less-than-or-equal-to c8 to prevent any future incompatible version of setuptools from breaking it... but then it couldn't take advantage of any bug-fixes in setuptools, and would cause conflicts when other packages were installed.
I'm guessing Linux package managers use a format declaration that tells their installer what format they are created in so that the installer can decide how to install older packages.
The other bugs... well, the weird new dependency for PyOpenGL... I just walked away from that one... just too weird, too arbitrary.
I just never figured out how to qualify the Twisted+Athena+TurboGears issues. *Something* was breaking when I tried to install that set (plus Elixir and SQLAlchemy and the rest) into my virtualenv environment(s). It looked like the pkg_resources plugin mechanism got confused and started pulling packages from the root path? Having spent 2 days hashing the system (eventually deleting almost all Python packages from the system to prevent them getting picked up) trying to get it to work (which I did eventually in one virtualenv which had had dozens of different approaches attempted) I wasn't able to isolate the problem or come up with a sequence of actions that would get around it to reproduce the environment.
Luckily we got rid of the c9-requiring package, so the latest versions can use c8 and do a regular TurboGears install.
For PyOpenGL/OpenGLContext, the complexity and relative opacity of the setuptools operations are such that I found it easier to replace my usage with a few dozen lines of custom code for writing plugins.
I recognize that setuptools has been key for lots of projects, but with the number of support requests I get for help with setuptools issues just about matching those for the actual project, it seems safer to just write a few dozen lines of code to provide custom plugin support and rewrite the setup scripts to use raw distutils.
That should make us compatible with py2exe, pyinstaller, and just about anything else you care to name in the Python world. It will mean I need to write a script to package up the dependencies in a downloadable form, but that's a few hours work and lets people behind firewalls use the results too.