matplotlib-devel Mailing List for matplotlib

On Wed, Aug 31, 2011 at 20:16, Matthew Brett <mat...@gm...> wrote:
> The issue being - why not have all the development branches in the
> same main repo?
>
> Because:
>
> a) Everyone needs write access to the main repo
> b) It's much less tempting to start experimental and highly unstable branches
> c) You can get a very similar effect by adding remotes to your own repo.
> d) It only very slightly simplifies an unusual case (what's developer
> X working on today?).
Limited internet access here, so no time for a long discussoin... Just
to say that I'm totally in agreement with Matthew here.
We only make branches in the main ipython repo under exceptional
circumstances, when there's a major piece of work that requires
multiple-developer commit collaboration to beat into shape and
cross-pulling from personal repos would just get annoying. But once
those are ready and merge we delete them as visible branches right
away.
For example, since we moved to github, we've only done this *twice*:
once for the big parallel rewrite, and once for the notebook work.
Both of these were *major* efforts that took months to shape up, so it
made sense to have them in there. But we make such a decision only
for such special cases, otherwise following the workflow Matthew
points out seems to work really well.
Once you get into the habit of using multiple remotes to get a handle
of an entire team's worth of contributions to a project, you realize
how simple and effective it is.
Cheers,
f

Hi,
On Wed, Aug 31, 2011 at 8:37 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett <mat...@gm...> wrote:
>> Yo,
>>
>> On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jd...@gm...> wrote:
>>> github workflow: this seems to present a different workflow than that
>>> espoused in gitwash used by mpl and other projects
>>>
>>> http://scottchacon.com/2011/08/31/github-flow.html
>>>
>>> I like the idea of lots of feature branches off upstream/master and
>>> master always being deployable (nightly builds?).  What is the
>>> advantage of core devs working in their own forks, as we currently do,
>>> over working on feature branches off of
>>> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight
>>> approach that works, and it would probably make it easier for users to
>>> follow mpl development by tracking the mpl repo and all the branches
>>> off of it, rather than having to pull in the various dev's forked
>>> branches.
>>
>> The issue being - why not have all the development branches in the
>> same main repo?
>>
>> Because:
>>
>> a) Everyone needs write access to the main repo
>
> I'm thinking about core devs here -- they all have write access to the
> main repo.  Users and non core devs can continue with the fork
> approach.
Will you document both workflows?
Will the core-devs have to keep track of two working sets that belong
to them, some in forks and some on the main repo?
Will you document what criteria the core-devs should use for this transfer?
I suppose I can see that the one-repo workflow would make sense for 20
people in the same building working on a private repo, but, for y'all,
with people coming in all the time saying, hey, I've got a patch, and
much less direct contact between the developers, I'd be really
surprised if it wasn't substantially more complicated than what you
have.
>> b) It's much less tempting to start experimental and highly unstable branches
>
> This can still be done in forks. And experimental and unstable
> branches are a minor threat -- they may increase the signal-to-noise,
> but dead branches can be pruned and users and devs can probably get a
> pretty good feel for which are active by looking at the "last update"
> time on the branch list.
Right - or follow Benjamin's suggestion, which seems very reasonable,
of having one or two sensible branches in your main repo, like, master
(maybe always deployable) and feature-several-of-us-are-working on,
and just do pull requests from forks into whichever one make sense.
>> c) You can get a very similar effect by adding remotes to your own repo.
>
> Yes, I do this and I'm sure other mpl developers do to, but you need
> to know who to follow, which is harder for the casual developer or
> user. By having the core devs develop in feature branches off of
> upstream, it makes it easier for users and other developers to see
> what all the other cores devs are up to w/o having to specify who to
> track. They track the main repo, they see the main work of the core
> devs as they come and go.
>
>> d) It only very slightly simplifies an unusual case (what's developer
>> X working on today?).
>
> I think it simplifies it dramatically, because the average user or
> part time developer doesn't have to ask "which developers should I
> follow?" and do the work to add them to externals. They can assume
> that by tracking the upstream branches, they see the important
> non-experimental branches the core developers are working on. It is
> easy to follow developer X if you know a priori who X is. But since
> 95% of the work is done by people who have write access to the central
> repo, and 95% of the users want to track this, it makes sense to me to
> push more of the workflow into the central repo, while still
> supporting external contributions via pull requests from forks.
I'm the core dev on a couple of projects, and I almost never want the
thing that you want, which is to see what everyone is working on right
now. I don't think I've knowingly come across the user who is a) not
up to adding remotes to the repo and b) will benefit from seeing or
want to see what everyone is working on. I'm not saying they aren't
out there, it's just not something I've considered.
> Maybe I'm missing something, but I feel the gitwash workflow is more
> complicated than it needs to be and this article re-inforces that
> view.
I'm missing it though - isn't the article describing a work-flow
substantially the same as gitwash?
That's what I meant in my reply, the one-repo thing is - as far as I
can see - only a minor difference from what you have.
Is that what you meant? Just the one-repo thing?
See you,
Matthew

On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
> I went here:
>
> http://matplotlib.sourceforge.net/api/index_backend_api.html
>
> and didn't see tkagg listed.
>
> Trevor
Trevor,
Thank you. It is still missing from the devel branch, along with 
several others. I can see how this could cause some confusion. Maybe 
we can get it fixed before the next release, maybe not.
Part of the problem here is that auto-generation of docs saves a huge 
amount of work, but can also lead to problems, of which this is just one 
example.
Eric
>
>
> ----- Original Message -----
> From: "Eric Firing"<ef...@ha...>
> To: mat...@li...
> Sent: Wednesday, August 31, 2011 10:33:45 AM
> Subject: Re: [Matplotlib-users] Matplotlib 1.0.1 Tk backend
>
> On 08/31/2011 04:01 AM, Trevor J Christensen wrote:
>> In preparing to upgrade from 0.99 to 1.0.1, I was reading the online
>> documentation about the various backends. I do not see a TkAgg backend
>> listed. Is that because there is no longer a backend for Tk? Has support
>> for Tk been dropped in 1.0.1? Or has it not yet been added to the
>> documentation?
>>
>> Trevor
>
> Trevor,
>
> Where did you expect to find it, but not see it?
>
> Eric
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett <mat...@gm...> wrote:
> Yo,
>
> On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jd...@gm...> wrote:
>> github workflow: this seems to present a different workflow than that
>> espoused in gitwash used by mpl and other projects
>>
>> http://scottchacon.com/2011/08/31/github-flow.html
>>
>> I like the idea of lots of feature branches off upstream/master and
>> master always being deployable (nightly builds?).  What is the
>> advantage of core devs working in their own forks, as we currently do,
>> over working on feature branches off of
>> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight
>> approach that works, and it would probably make it easier for users to
>> follow mpl development by tracking the mpl repo and all the branches
>> off of it, rather than having to pull in the various dev's forked
>> branches.
>
> The issue being - why not have all the development branches in the
> same main repo?
>
> Because:
>
> a) Everyone needs write access to the main repo
I'm thinking about core devs here -- they all have write access to the
main repo. Users and non core devs can continue with the fork
approach.
> b) It's much less tempting to start experimental and highly unstable branches
This can still be done in forks. And experimental and unstable
branches are a minor threat -- they may increase the signal-to-noise,
but dead branches can be pruned and users and devs can probably get a
pretty good feel for which are active by looking at the "last update"
time on the branch list.
> c) You can get a very similar effect by adding remotes to your own repo.
Yes, I do this and I'm sure other mpl developers do to, but you need
to know who to follow, which is harder for the casual developer or
user. By having the core devs develop in feature branches off of
upstream, it makes it easier for users and other developers to see
what all the other cores devs are up to w/o having to specify who to
track. They track the main repo, they see the main work of the core
devs as they come and go.
> d) It only very slightly simplifies an unusual case (what's developer
> X working on today?).
I think it simplifies it dramatically, because the average user or
part time developer doesn't have to ask "which developers should I
follow?" and do the work to add them to externals. They can assume
that by tracking the upstream branches, they see the important
non-experimental branches the core developers are working on. It is
easy to follow developer X if you know a priori who X is. But since
95% of the work is done by people who have write access to the central
repo, and 95% of the users want to track this, it makes sense to me to
push more of the workflow into the central repo, while still
supporting external contributions via pull requests from forks.
Maybe I'm missing something, but I feel the gitwash workflow is more
complicated than it needs to be and this article re-inforces that
view.
JDH

On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett <mat...@gm...>wrote:
> Yo,
>
> On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jd...@gm...> wrote:
> > github workflow: this seems to present a different workflow than that
> > espoused in gitwash used by mpl and other projects
> >
> > http://scottchacon.com/2011/08/31/github-flow.html
> >
> > I like the idea of lots of feature branches off upstream/master and
> > master always being deployable (nightly builds?). What is the
> > advantage of core devs working in their own forks, as we currently do,
> > over working on feature branches off of
> > https://github.com/matplotlib/matplotlib? Seems like a lighter-weight
> > approach that works, and it would probably make it easier for users to
> > follow mpl development by tracking the mpl repo and all the branches
> > off of it, rather than having to pull in the various dev's forked
> > branches.
>
> The issue being - why not have all the development branches in the
> same main repo?
>
> Because:
>
> a) Everyone needs write access to the main repo
> b) It's much less tempting to start experimental and highly unstable
> branches
> c) You can get a very similar effect by adding remotes to your own repo.
> d) It only very slightly simplifies an unusual case (what's developer
> X working on today?).
>
> Less tempting
> ------------------
> Just as a minor example, here's my nipy branch list:
>
> https://github.com/matthew-brett/nipy/branches
>
> Lots of crap in there; I just made a branch with a single extra commit
> that I may well throw away, the branch I'm currently working on:
>
> https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor
>
> - I am constantly rebasing and reorganizing while I try to work out
> what I'm doing. I'd think much harder about that if I thought other
> people were expecting to pull down all my stuff. Thinking harder =
> slower coding (for me at least :))
>
> Similar effect
> ----------------
>
> - I'd like to see what Gael and Jonathan Taylor are up to from time to
> time:
>
> Once:
> git clone gi...@gi...:matthew-brett/nipy.git # origin remote
> git remote add gael git://github.com/GaelVaroquaux/nipy.git
> git remote add jonathan git://github.com/jtaylor/nipy.git
>
> >From time to time:
> git fetch --all
>
> - same effect, and it allows me to chose who I'm following. But
> actually, I very rarely do that in the abstract, I look when they tell
> me to look at something, and I'm pretty sure it's the same for them
> and my stuff.
>
> See you,
>
> Matthew
>
>
I agree with Matthew here, but I could see a possible hybrid approach.
Let's say we were a more organized group (I will wait for the laughter to
die down...), then one could imagine having branches with names of approved
milestones/goals/planned features for the next release. The names would
convey the features actively being worked on, and provide a focus for us.
When a feature is finished, we then merge into master. If a feature is not
ready for prime-time, then we can just hold it off.
Just a thought,
Ben Root

Yo,
On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jd...@gm...> wrote:
> github workflow: this seems to present a different workflow than that
> espoused in gitwash used by mpl and other projects
>
> http://scottchacon.com/2011/08/31/github-flow.html
>
> I like the idea of lots of feature branches off upstream/master and
> master always being deployable (nightly builds?).  What is the
> advantage of core devs working in their own forks, as we currently do,
> over working on feature branches off of
> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight
> approach that works, and it would probably make it easier for users to
> follow mpl development by tracking the mpl repo and all the branches
> off of it, rather than having to pull in the various dev's forked
> branches.
The issue being - why not have all the development branches in the
same main repo?
Because:
a) Everyone needs write access to the main repo
b) It's much less tempting to start experimental and highly unstable branches
c) You can get a very similar effect by adding remotes to your own repo.
d) It only very slightly simplifies an unusual case (what's developer
X working on today?).
Less tempting
------------------
Just as a minor example, here's my nipy branch list:
https://github.com/matthew-brett/nipy/branches
Lots of crap in there; I just made a branch with a single extra commit
that I may well throw away, the branch I'm currently working on:
https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor
- I am constantly rebasing and reorganizing while I try to work out
what I'm doing. I'd think much harder about that if I thought other
people were expecting to pull down all my stuff. Thinking harder =
slower coding (for me at least :))
Similar effect
----------------
- I'd like to see what Gael and Jonathan Taylor are up to from time to time:
Once:
git clone gi...@gi...:matthew-brett/nipy.git # origin remote
git remote add gael git://github.com/GaelVaroquaux/nipy.git
git remote add jonathan git://github.com/jtaylor/nipy.git
>From time to time:
git fetch --all
- same effect, and it allows me to chose who I'm following. But
actually, I very rarely do that in the abstract, I look when they tell
me to look at something, and I'm pretty sure it's the same for them
and my stuff.
See you,
Matthew

github workflow: this seems to present a different workflow than that
espoused in gitwash used by mpl and other projects
http://scottchacon.com/2011/08/31/github-flow.html
I like the idea of lots of feature branches off upstream/master and
master always being deployable (nightly builds?). What is the
advantage of core devs working in their own forks, as we currently do,
over working on feature branches off of
https://github.com/matplotlib/matplotlib? Seems like a lighter-weight
approach that works, and it would probably make it easier for users to
follow mpl development by tracking the mpl repo and all the branches
off of it, rather than having to pull in the various dev's forked
branches.

On Wed, Aug 31, 2011 at 8:49 PM, John Hunter <jd...@gm...> wrote:
>> Note that I'm not subscribed to this list, so please CC me on replies.
>
> That won't work because mpl converts all tex png raster to black and
> white and handles color on its own in post-processing. The following
> does work:
>
> import numpy , pylab
>
> x = numpy.arange( 0.0 , 5.0 )
> pylab.rc( 'text' , usetex=True )
> pylab.title( r'$\rm{colored\ title\ wanted}$', color='blue' )
> pylab.plot( x )
> pylab.savefig( 'test.png' )
> pylab.show()
But since you set usetex, you shouldn't need the $ escapes and the
literal rm font. It should be enough to do:
pylab.title( r'colored title wanted 2.5', color='blue' )\
JDH

On Sat, Aug 27, 2011 at 4:15 PM, Michael Gilbert
<mic...@gm...> wrote:
> Hi,
>
> I'm trying to generate colored text on my plots, but  can only seem
> to get black and white. I've attached an example python scriptx
> (test.py) that demonstrates the problem. This produces a plot
> (test.png) with black and white text even though I've explicitly told
> latex to use color, and in fact the intermediate image gets colored
> correctly (attached 25a9904ac88febf5f01477f069213537.png file taken
> from .matplotlib/tex.cache). I'm currently using matplotlib 0.99.3.
> Thanks for any help with this issue.
>
> Note that I'm not subscribed to this list, so please CC me on replies.
That won't work because mpl converts all tex png raster to black and
white and handles color on its own in post-processing. The following
does work:
import numpy , pylab
x = numpy.arange( 0.0 , 5.0 )
pylab.rc( 'text' , usetex=True )
pylab.title( r'$\rm{colored\ title\ wanted}$', color='blue' )
pylab.plot( x )
pylab.savefig( 'test.png' )
pylab.show()
>
> Best wishes,
> Mike
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Wed, Aug 31, 2011 at 7:34 PM, Benjamin Root <ben...@ou...> wrote:
> Hello all,
>
> In my continuing quest to get style cycles working, I wanted to get
> errorbar() to support it as well. Unfortunately, errorbar() has a default
> kwarg 'fmt' that takes a value of '-', and *None* already has a special
> meaning in errorbar(). Therefore, I wanted to determine if the user wants
> to use the stylecycle by seeing if 'fmt' does not get specified in the call
> to errorbar(). This requires removing the 'fmt' kwarg from the call
> signature for errorbar() in axes.py.
>
> Of course, changing the call signature for errorbar() in axes.py would
> require changing the call signature in pyplot.py. But this is supposed to
> be done by boilerplate.py. How/when during the build does this file get
> called? Also, pyplot.py is under revision control, so it seems to be a bit
> odd to have auto-generated files under revision control (or is it just me?).
>
> Is boilerplate.py antiquated? Should we give it another look after the v1.1
> release?
boilerplate is called manually when you want to add a new function to
pyplot, and you manually remove all the lines from pyplot.py from the
first instance of
 # This function was autogenerated by boilerplate.py. Do not edit as
 # changes will be lost
to the end, and replace it with the output of boilerplate.py. We
could automate this, or make it better, eg by having boilerplate.py
generate some module like _pyplot_boilerplate.py and having pyplot do
an import * from that, but for now you can just do it the manual way
if you prefer,
JDH

Hello all,
In my continuing quest to get style cycles working, I wanted to get
errorbar() to support it as well. Unfortunately, errorbar() has a default
kwarg 'fmt' that takes a value of '-', and *None* already has a special
meaning in errorbar(). Therefore, I wanted to determine if the user wants
to use the stylecycle by seeing if 'fmt' does not get specified in the call
to errorbar(). This requires removing the 'fmt' kwarg from the call
signature for errorbar() in axes.py.
Of course, changing the call signature for errorbar() in axes.py would
require changing the call signature in pyplot.py. But this is supposed to
be done by boilerplate.py. How/when during the build does this file get
called? Also, pyplot.py is under revision control, so it seems to be a bit
odd to have auto-generated files under revision control (or is it just me?).
Is boilerplate.py antiquated? Should we give it another look after the v1.1
release?
Cheers!
Ben Root