Re: [matplotlib-devel] basemap installation problem with mpl master

[Damon M. <dam...@gm...>]

On Sat, Jul 6, 2013 at 12:20 PM, Eric Firing <ef...@ha...> wrote:

> On 2013/07/06 5:32 AM, Damon McDougall wrote:
>
>>
>>
>>
>> On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> 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.


No worries.  All I did was use matplotlib's distribute_setup.py file and
add the lines

from distribute_setup import use_setuptools
use_setuptools()

to setup.py.

I'm sure there's extra setuptools foo I need to make it play nicely with
the matplotlib egg, but I haven't at all looked into it in any detail.


>
>
>
>> 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.
>

Ah yes, that's entirely reasonable.


>
> 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.
>

That's sounds reasonable to me.  But there's a part of me that can't help
thinking that what we're trying to do should be entirely possible.  Perhaps
it's more hacky, though.


>
> 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.
>

I'm not against having it as a separate package.  We can deprecate the old
location and remove it in 1.5.x, say.


>
> 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...


Yes, I know.  It's a mess.  Also notice that it's really hard to downgrade
to maptlotlib version 1.3.x after having installed 1.4.x, because
setuptools creates an egg for each version.  In principle this is nice as,
I assume, it offers the flexibility to switch between different matplotlib
versions on the fly.  That said, I see no way to actually do this.


>
>
> 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
>>
>
>


-- 
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