|
From: Robert K. <rob...@gm...> - 2006-01-25 18:06:48
|
Charlie Moad wrote: > I left the check for this env variable there for this reason. Just in > case someone wants to put the data somewhere else on the system. It > doesn't support a list of directories now, but wouldn't you presume > the user who sets it knows where the data is? Privileges should not > be an issue at all now since the data is embedded in the module. Sure, but he may be putting data in multiple places (fonts in one directory, colormaps in another, basemap data in a third, etc.). Or only providing a few new pieces of data, not the complete suite of data. And once we use a path-based approach, it would be easy to keep fonts and other data in separate directories inside the package. You simply append both directories to the end of MATPLOTLIBDATAPATH. AFAICT, that's the only objection against moving the data into the lib/matplotlib/mpl-data/ in the source distribution. > I still think the best approach is going to be to specify the mpldata > as package_data, like it is, instead of data_files. Then all the > logic in the setup file goes away. I tried this, but distutils would > not respect "../fonts" type directories. We would actually have to > move the data files into the mpl module. Yes, I agree with you. Believe me, I'm not arguing against installing data in the package itself. > Matplotlib is a python plugin, not an application. I can't think of > any other python modules that dump their data files around the system > during installation. Oh, there are plenty, but they all suck for doing so. Unless if they are following a particular standard, like Gnome or KDE applications. -- Robert Kern rob...@gm... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |