At 12:20 AM 5/30/2005 -0500, Ian Bicking wrote: >I'm thinking maybe a better way to do this would be some sort of patch >process, so that I could distribute a setup.py seperately, or some other >custom build process, that easy_install could detect and run. > >And, of course, obviously I *could* fix these upstream, but I think this >is a useful problem to solve through easy_install, even if these >particular packages get fixed later.
Yes, I've kind of thought about doing that (patches, or special modes/options/whatever), but it seemed just a bit Microsofty, if you know what I mean. :) On the other hand, Microsoft's commitment to backward compatibility has been legendary, and it's not necessarily a bad thing to emulate. It should help us achieve Total World Domination more quickly, which is why I was willing to put in the research time to figure out how to do sandboxing. So, I guess there are two ends of the "backward compatibility" spectrum here: * Low-end: Single .py files and other setup-free distributions * High-end: Distributions that muck about with their installation paths in one way or another I've so far found that there are almost as many ways to hack package data paths as there are packages; through considerable tweaking I've managed to get bdist_egg now to handle more packages without virtualization, but it's a regression-testing nightmare, because all the stuff is order sensitive, and stuff that looks unnecessary is in fact necessary to support different packages' ways of getting at the same information. I think, however, that all of those kludges will have to stick around until Python 2.6, using the Python 2.5 timeframe to warn that 'data_files' should not be used to install data into site-packages, and that 'package_data' is the correct approach. As for me, at the moment I've successfully gotten aquarium, IPython, and numarray to install their data only into their eggs, without any virtualization. So I'll be checking those kludges in momentarily. I have to say that in hindsight, the absence of adequate support for package-data installation in previous versions of the distutils was perhaps its single largest flaw. It appears very rare that anybody ever creates custom distutils commands, unless they needed to in order to work around that problem. As a consequence, it makes it much harder to get bdist_egg to trap such installs and route them to the right place. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
