matplotlib-devel Mailing List for matplotlib

It was me :-)
Only a day to day user who follow matplotlib (and other famous libs)
development. I clicked on the survey thinking it was public. Anyway it was
only curiosity so if you prefer keep it secret, it's cool for me !
Keep the good work guys !!!
--
HadiM
On Thu, Jul 18, 2013 at 12:12 AM, Paul Ivanov <pi...@be...> wrote:
> Hey everyone,
>
> I hope this email finds you well. I got a request today from
> someone wanting to look at the survey results. How do you feel
> about just sharing the full document? We're at 580 responses
> right now, and it's been really a slow trickle in last couple of
> weeks after the initial splash. Or we could do another round on
> twitter and G+ and say the survey will be closed at the end of
> the month, and then release the results.
>
> Thoughts?
>
> best,
> --
> _
> / \
> A* \^ -
> ,./ _.`\\ / \
> / ,--.S \/ \
> / `"~,_ \ \
> __o ?
> _ \<,_ /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hey everyone,
I hope this email finds you well. I got a request today from
someone wanting to look at the survey results. How do you feel
about just sharing the full document? We're at 580 responses
right now, and it's been really a slow trickle in last couple of
weeks after the initial splash. Or we could do another round on
twitter and G+ and say the survey will be closed at the end of
the month, and then release the results.
Thoughts?
best,
-- 
 _
 / \
 A* \^ -
 ,./ _.`\\ / \
 / ,--.S \/ \
 / `"~,_ \ \
 __o ?
 _ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

On 2013年07月17日 3:14 AM, Michael Droettboom wrote:
> Yes. This is great work!
>
> Just to chime in (after having been away for most of this conversation) -->
>
> I think we can do this reorganization now without introducing any
> implicit (or otherwise) use of gca()/pyplot stuff in the Axes class
> methods. Refactoring how the pyplot wrapper is done can be done as a
> separate project at a later time (or even in parallel if someone wants
> to, since all of Nelle's work at the end of the day doesn't change the
> Axes interface).
>
> My only other comment (and I mentioned this in PR #2213 as well) is that
> having the short stub functions in the Axes class in addition to the
> actual implementations elsewhere introduces a new
> synchronization/maintenance problem between the two. Maybe it makes
> sense to merely add the implementation functions to the Axes class
> namespace dynamically. Magical, sure, but should have ultimately the
> same result as far as introspection, autocompletion and other IPython
> goodness is concerned.
>
> Mike
Mike,
One other option is to have the new private modules include mixin 
classes from which Axes would inherit methods. There would be a lot of 
mixins, and this would be an example of the dreaded multiple 
inheritance, but it would be simple and explicit, with no magic.
Eric

I've started a MEP related to improving our continuous integration 
system for matplotlib.
https://github.com/matplotlib/matplotlib/wiki/Mep19
Rather than deal to much with implementation at this point, I thought it 
best to start by outlining our requirements. At this point, let's just 
get everything we'd like in, and we can worry about prioritizing things 
later.
Once that's done, we can start discussing how to get things set up. We 
have some donation money to use for buying machines or paying for 
services, so we are not limited to what is available for free. I would 
particularly like feedback from others who have set up similar things. 
I have some experience with ShiningPanda (a service based on Jenkins), 
and Travis. We used buildbot in the past, but I have little direct 
experience with it. Are there other obvious candidates or approaches?
Mike

Yes. This is great work!
Just to chime in (after having been away for most of this conversation) -->
I think we can do this reorganization now without introducing any 
implicit (or otherwise) use of gca()/pyplot stuff in the Axes class 
methods. Refactoring how the pyplot wrapper is done can be done as a 
separate project at a later time (or even in parallel if someone wants 
to, since all of Nelle's work at the end of the day doesn't change the 
Axes interface).
My only other comment (and I mentioned this in PR #2213 as well) is that 
having the short stub functions in the Axes class in addition to the 
actual implementations elsewhere introduces a new 
synchronization/maintenance problem between the two. Maybe it makes 
sense to merely add the implementation functions to the Axes class 
namespace dynamically. Magical, sure, but should have ultimately the 
same result as far as introspection, autocompletion and other IPython 
goodness is concerned.
Mike
On 07/11/2013 11:47 PM, Tony Yu wrote:
> Nelle, this is great! Thanks for getting the ball rolling!
>
> Cheers,
> -Tony
>
>
> On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux 
> <nel...@gm... <mailto:nel...@gm...>> wrote:
>
> FYI, I have started the refactoring we discussed at scipy. I think
> what tony is suggesting is the same thing.
>
> I've created a "work in progress" pull request:
> https://github.com/matplotlib/matplotlib/pull/2213
>
> In the refactoring we discussed at Scipy, we did not mention the
> pyplots wrapper at all. It does not impact pyplot or the axes module
> at all as it doesn't change the API at all. If we want to do something
> more in depth that impacts the API, I think it would be worth writing
> a MEP.
>
> Thanks,
> N
>
>
> On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...
> <mailto:ant...@gm...>> wrote:
> > Eric Firing <efiring@...> writes:
> >>
> >> Anton,
> >>
> >> Yes, I have done things like that in my own code, and basemap has a
> >> similar ability to call gca() when an Axes is not supplied.
> One can
> >> even perform the pyplot import on an as-needed basis instead of
> raising
> >> an error. Nevetheless, it still represents what I view as a big
> change
> >> in mpl design, scrambling the state machine pyplot layer into
> the OO
> >> layer. Sometimes this sort of thing is good, sometimes it
> isn't. In
> >> the present case, I am far from convinced that it would be good. I
> >> don't see any real benefit at all over the present design. I
> think that
> >> for the sanity of the developers, if nothing else, it is
> important to
> >> maintain some clear layering and hierarchy.
> >>
> >> Eric
> >>
> >
> > I completely agree with that, and I just wanted to point out the
> possibility.
> > With the proposed separation of the plots to a separate module,
> I think, the
> > reasonable thing for pyplot would be to wrap the corresponding
> plot functions
> > by feeding gca into the axis argument.
> >
> > PS for what I think, pyplot right now is way too thick of a layer,
> > obstructing an API use of backends.
> >
> > Anton
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from
> AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Sorry to just be getting to this discussion now, after a vacation.
The move to setuptools was discussed at length as part of MEP11. See 
here: https://github.com/matplotlib/matplotlib/wiki/MEP11 and the MEP11 
mailing list thread.
It has been a long standing bug that we ship Python dependencies along 
with matplotlib. Users were reporting pyparsing bugs to matplotlib, 
assuming it was a matplotlib project, etc. That was the primary impetus 
for moving to setuptools: so that pip dependency resolution would work. 
It has not been without headaches -- the "remerge" of distribute back 
into setuptools in particular was handled really poorly by upstream. I 
do hope that now that the community has re-coalesed around the "new" 
setuptools and the move from eggs to wheels that things will get better 
in the near future. But I still think the new approach is far better 
than what we had.
Sorry that the namespace package declaration was missed and fell through 
the cracks, but I'm glad we noticed it before 1.3.0 final. Is it the 
case that PR #2210, or are there still issues to be resolved?
Mike
On 07/06/2013 01:59 PM, Jeff Whitaker wrote:
>> Thomas Kluyver <mailto:th...@kl...>
>> July 6, 2013 11:26 AM
>>
>> *distribute*, which was a fork of setuptools, was merged into 
>> setuptools. *distutils* is the component in the standard library, and 
>> is still there. I still prefer distutils where possible, precisely 
>> because setuptools' eggs are a mess.
>>
>> Thomas
>
> I agree eggs are a mess. Given that it is still easy to have the old 
> behavior, can someone explain why the change was made to have setup.py 
> create eggs by default?
>
> -Jeff
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 11:20 AM
>>
>>
>>
>> On Sat, Jul 6, 2013 at 11:04 AM, Jeff Whitaker <js...@fa... 
>> <mailto:js...@fa...>> wrote:
>>
>>> Damon McDougall <mailto:dam...@gm...>
>>> July 6, 2013 9:32 AM
>>>
>>>
>>>
>>> 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.
>>>
>>> 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?
>>
>> What if a user decides later that he/she wants to install
>> basemap? Then they would have to reinstall matplotlib? That
>> doesn't sound reasonable to me.
>>
>>
>> Actually, on reflection, I'm in agreement with you. I'm comfortable 
>> installing from source but this poses a larger problem when users 
>> download the basemap binary and expect it to Just Work.
>>
>> How about having matplotlib install a symlink to the egg location?
>>
>>
>> If there's a way for setuptools to modify the matplotlib egg to add a 
>> symlink, then it must be possible for setuptools to just put the 
>> files there. I just haven't figured out how to do that.
>>
>> Why the change to using setuptools by default in the first place?
>>
>>
>> Long story. The short story is that distutils was merged into 
>> setuptools. So setuptools is now the recommended way to install 
>> python packages.
>>
>>
>> -Jeff
>>>
>>> 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
>>> Eric Firing <mailto:ef...@ha...>
>>> July 6, 2013 12:53 AM
>>> 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.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> -- 
>> 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
>> Jeff Whitaker <mailto:js...@fa...>
>> July 6, 2013 10:04 AM
>>> Damon McDougall <mailto:dam...@gm...>
>>> July 6, 2013 9:32 AM
>>>
>>>
>>>
>>> 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.
>>>
>>> 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?
>>
>> What if a user decides later that he/she wants to install basemap? 
>> Then they would have to reinstall matplotlib? That doesn't sound 
>> reasonable to me.
>>
>> How about having matplotlib install a symlink to the egg location?
>>
>> Why the change to using setuptools by default in the first place?
>>
>> -Jeff
>>>
>>> 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
>>> Eric Firing <mailto:ef...@ha...>
>>> July 6, 2013 12:53 AM
>>> 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.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 9:32 AM
>>
>>
>>
>> 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.
>>
>> 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?
>>
>> 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
>> Eric Firing <mailto:ef...@ha...>
>> July 6, 2013 12:53 AM
>> 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.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel