Re: [matplotlib-devel] Default matplotlib data path

[Charlie M. <cw...@gm...>]

On 1/25/06, Robert Kern <rob...@gm...> wrote:
> 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 a=
nd so
> sets the data path for that. However, that's not always the case. For exa=
mple,
> 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 t=
he data
> path ends up being incorrect.

I have ran into this as well, and it is just coming from the game of
trying to make the setup file work with distutils and setuptools.

> 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 prefe=
rably
> only one --obvious way to do it," principle everywhere it possibly can, i=
t 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 with=
out
> privileges to manipulate site-packages or /usr/local/share to make replac=
ements
> or additions.

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.

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.

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.  I have seen many projects though with
glade/png/etc. files embedded into the module as package_data and they
avoid all these issues mentioned above.