matplotlib-devel Mailing List for matplotlib

Hi all!
Attached a very simple patch to show "matplotlib.patches" correctly in
the docpage above.
Thanks for considering,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Andrew Straw wrote:
> For the past month or two, I've been experimenting with using git to
> interact with the MPL subversion repository. The bottom line is that I I
> haven't been able to create any kind of one-to-one mapping between git
> branches and svnmerge.py branches. As we're using svnmerge.py on top of
> subversion to manage the trunk and release branches, I see this as a
> pretty fatal flaw.
> 
I basically agree with Andrew, but I want to elaborate on this point for 
those who haven't been trying this stuff out for themselves.
I documented how to use svn maintenance branches from git, and this is 
in the matplotlib source, but doesn't seem to have pushed out to the 
sourceforge site. This might be due to the automatic doc updating being 
turned off recently -- I haven't followed that thread closely. Because 
of this, I don't know if Andrew's comments aren't taking that into 
account... he could have reached the same conclusion either way... :)
It is possible to work on maintenance branches from git, but I haven't 
figured out a way to do the merging without svnmerge.py. I've worked 
this way for a while, and yes it's kludgy, but not too bad. I just keep 
a SVN checkout of the trunk around specifically for running 
svnmerge.py. So there is a one-to-one mapping between svn branches and 
git branches, it's just not a bidirectional one-to-one mapping, and 
unfortunately any advantages to git's merging tools are useless in that 
situation. But, honestly, I haven't really missed them.
> So, while I can use git to interact with the trunk (and create and use
> my own feature branches locally using git), and while using git is very
> nice for browsing history or bisecting the revision in which a bug
> cropped up, I think I've reached a point where I don't think interaction
> with svnmerge.py's branches is going to work without investing more time
> than I'm willing to give into understanding (and possibly improving)
> git-svn.
> 
My own gut feeling is that while a pure DVCS environment might be nice 
someday, the compromises of git-svn makes the whole thing sort of +0 for 
me. I can't say that I've felt much more productive using it over raw 
svn/svnmerge.py with matplotlib. So I, too, am giving it a pass for 
now, but for slightly different reasons.
> So, therefore, I'd say the issue of using a distributed version control
> system for MPL has not reached any real conclusion. Thus, we may want to
> visit this issue at some point. Perhaps once Python and/or numpy have
> made decisions. The Python-dev team seems to be working this out right
> now: http://www.python.org/dev/peps/pep-0374/
> 
I like the approach the PEP (Brett Cannon) is taking. I think it makes 
a lot of sense to let those dedicated and smart core Python folks do 
some trailblazing for us :)
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

For the past month or two, I've been experimenting with using git to
interact with the MPL subversion repository. The bottom line is that I I
haven't been able to create any kind of one-to-one mapping between git
branches and svnmerge.py branches. As we're using svnmerge.py on top of
subversion to manage the trunk and release branches, I see this as a
pretty fatal flaw.
So, while I can use git to interact with the trunk (and create and use
my own feature branches locally using git), and while using git is very
nice for browsing history or bisecting the revision in which a bug
cropped up, I think I've reached a point where I don't think interaction
with svnmerge.py's branches is going to work without investing more time
than I'm willing to give into understanding (and possibly improving)
git-svn.
So, therefore, I'd say the issue of using a distributed version control
system for MPL has not reached any real conclusion. Thus, we may want to
visit this issue at some point. Perhaps once Python and/or numpy have
made decisions. The Python-dev team seems to be working this out right
now: http://www.python.org/dev/peps/pep-0374/
-Andrew

On Wed, Feb 4, 2009 at 17:08, Jayson Barr <jb...@nm...> wrote:
> 2). If the Tk/Tcl libraries were installed from source instead of
> using the binaries you suggested installing, then it will just use the
> wrong system Framework anyway. I bet people using macports and other
> unix-like package managers on mac end up submitting a lot of bug
> reports over this.
It did for MacPorts, there where a lot of strange segfaults reported.
I have since hacked round this to force it to link against the
MacPorts provided Tcl/Tk
http://trac.macports.org/browser/trunk/dports/python/py25-matplotlib/files/patch-setupext.py.diff
Its messy but it works.
Cheers
Adam