Charlie Moad wrote: > Short explanation: > Use --prefix instead > > Long explanation: > Without explicitly moving around files in cvs and declaring the > mpl data as package_data, it is pretty hard to be 100% compliant. The > code you put below is basically how distutils now determines where to > stick data_files, and that is why I used it as a guide too faking it. > --home is unix specific I think, and I don't know that it gives you > any power over --prefix. --install-data is useless now since the data > is embedded into the matplotlib module itself. There is another problem with the current approach. The current setup.py assumes that if you have an egg-capable setuptools that you are building an egg and so sets the data path for that. However, that's not always the case. For example, the --single-version-externally-managed option should install matplotlib and company as regular Python packages into site-packages (or wherever) with a .egg-info/ directory alongside. This is how Debian (and presumably other distros) is going to install eggified packages. However, the choice for the data path ends up being incorrect. I think a general rule might be to say that the innards of distutils are usually a bad example for *using* distutils. It makes a lot of assumptions inside, and the current mechanism in mpl's setup.py is fairly fragile. distutils is a piece of junk, and really, really violates the "There should be one-- and preferably only one --obvious way to do it," principle everywhere it possibly can, it seems. The most robust approach seems to be this: http://wiki.python.org/moin/DistutilsInstallDataScattered > I think I wrote a little a while back justifying the move, but > I'll restate. If you look at older versions of the > matplotlib._get_data_path() method, it was becoming a huge collection > of special cases. Those cases are still in cvs, but commented out. > It had the approach of try everything until I find the data. Now you > could acutally write this method in one line, "return > os.sep.join([os.path.dirname(__file__), 'mpl-data'])". However it > does a little more by still checking the MATPLOTLIBDATA env variable > first and verifying that the embedded mpl-data folder actually exists. Have we ever considered moving to a path-based solution? For example, one would set MATPLOTLIBDATAPATH to be a list of directories. When something inside matplotlib needs data, it will go through the list of directories looking for the file, and finally checking os.path.join([os.path.dirname(__file__), 'mpl-data']) if the file is not on the path. This would enable users without privileges to manipulate site-packages or /usr/local/share to make replacements or additions. -- Robert Kern rob...@gm... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter