On 2013/07/06 5:32 AM, Damon McDougall wrote: > > > > On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <efir...@hawaii.edu > <mailto:efir...@hawaii.edu>> wrote: > > If I do a clean install of mpl master, and then of basemap, basemap > lands in dist-packages/mpl_toolkits, as it always has. But now it is > not found--I can't import it. It seems that now the *real* mpl_toolkits > is cleverly hidden inside an egg directory with a monstrous name, > leaving basemap orphaned in a directory with no __init__.py. As a > workaround I can symlink it into the egg location. I suspect the real > solution will require basemap to use setuptools, correct? I don't know > how to do this, so I hope someone who does will submit a PR. > > > Actually, using the new setuptools isn't adequate, I just tried it > locally on my machine and it still doesn't install itself into the > matplotlib egg.
Thank you for giving it a try. > > I think the proper solution here is to add basemap as an optional > dependency to matplotlib and have the user set a flag (off by default) > to pull basemap if it's desired. > > Does that sound like a reasonable solution? No, unfortunately. First, because fundamentally, matplotlib is a dependency of basemap, not the other way around. Second, because I want to be able to pull basemap from git and do the usual "setup.py build, setup.py install" independently of matplotlib. It sounds like the only real solution will be for basemap to live as an independent package in dist-packages, and drop the mpl_toolkits umbrella entirely. I don't see that it does any good anyway. It seems setuptools has irretrievably broken the usefulness of mpl_toolkits as anything other than a place to put sub-packages that are distributed with mpl, and that live in the same git repo. Moving basemap out of mpl_toolkits would also simplify the basemap directory structure. I don't see any downside other than the pain of the transition itself, including the problem of user code needing to have every import of basemap handle both possible locations. The setuptools arrangement of having mpl_toolkits hidden in an egg, but still imported as "import mpl_toolkits", seems like a horrible design. I'm also uncomfortable with the new behavior in which the standard command to build and install mpl triggers an avalanche of potential package installations. Oh, well... Eric > > P.S. Note that the other mpl_toolkits are installed into the correct > place because they are shipped with matplotlib and installed at the same > time. We could ship basemap with matplotlib too but it's a rather large > download. > > Best wishes, > Damon > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
