matplotlib-devel Mailing List for matplotlib

Hi all,
I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run. I'll attempt to work through these, and you can
check progress on the nascent buildbot display here:
http://mpl-buildbot.code.astraw.com
(If the DNS update hasn't propagated to your DNS server yet, you can go
directly to http://code.astraw.com:8092/ )
In the meantime, please forgive a couple extra files I committed
(bootstrap.py and buildout.cfg) that are designed to get matplotlib to
adhere to buildout package standards.
Assuming I can get this working, I'll attempt to recruit further
buildslaves. In the interest of piquing your interest in running a
buildslave on your favorite platform(s), here is the contents of my
buildout.cfg file containing all of the configuration necessary. It's
pretty simple:
[buildout]
parts = ubuntu-hardy-amd64
[ubuntu-hardy-amd64]
recipe = collective.buildbot:slave
host = mpl-buildbot.code.astraw.com
port = 8090
password = <secret>

On Mon, May 18, 2009 at 10:41:22PM -0400, Darren Dale wrote:
> I had tried to work things out so mpl would only install traits if traits
> wasn't already installed, or if the installed version had also been
> provided by mpl. That turned out to be insufficient to avoid the problems
> [...]
> To make a long story short, it won't happen again.
Excellent. 
I do agree with both of you that shipping Traits with matplotlib is very
likely to get all of us in trouble.
If there are issue with having Traits as a dependency, they must be
adressed in the Traits codebase.
Gaël

On Mon, May 18, 2009 at 9:37 PM, Robert Kern <rob...@gm...> wrote:
> On 2009年05月18日 20:05, Darren Dale wrote:
> > On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...
> > <mailto:rob...@gm...>> wrote:
> >
> > On 2009年05月18日 19:07, Andrew Straw wrote:
> > > I've been hacking away at adding support for "dropped spines" to
> MPL
> > > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 )
> and
> > > have come to the conclusion that there is a fundamental issue in
> the
> > > code base that the traits package has solved -- many values that
> > depend
> > > on other values with complicated stuff that happens when one of
> the
> > > parent values changes. For example, the location of the text from
> the
> > > xaxis depends on the padding value in addition to the xaxis
> location.
> > > Now I'm trying to add another element to the mix -- namely an
> > axis spine
> > > that can change location -- and things are going to spiral into a
> > > (further) collection of special-cased updates unless there's some
> > > reworking of the infrastructure.
> > >
> > > So, the question is, should I attempt to use traits for this? I
> guess
> > > that I won't have the time to re-write the entire code base to use
> > > traits, but I'd like make a stab a stab at dropped spine support
> with
> > > the knowledge that, should I be successful, there's at least a
> > chance we
> > > would again ship traits with MPL. I imagine we could
> > incrementally move
> > > more and more to traits if I'm successful, particularly now that
> > we have
> > > the beginnings of a unit test infrastructure (thanks James!).
> >
> > If you do, *please* either depend on Traits or, if you must include
> > the code in
> > matplotlib itself, stick it under matplotlib's namespace.
> >
> >
> > We stopped shipping traits with mpl a long time ago, when that issue was
> > identified.
>
> But part of that calculation was that Traits wasn't being used for anything
> non-experimental. Since that is being revisited, and since you still do
> distribute other packages like dateutils and pytz (which also cause similar
> installation headaches) the same way, I would like this to be kept in mind.
>
> > I really don't want to
> > go back to having to fix people's broken installations again.
> >
> >
> > Was that comment really necessary?
>
> Was it really offensive?
The whole situation was just really embarrassing for me. Who would want to
go back to having to fix people's broken installations? It just opened an
old wound.
> People would install matplotlib, then they would try to
> install other parts of ETS, the ETS stuff wouldn't work, thus they had a
> broken
> installation. I do not want to go back to having to fix their broken
> installations. This isn't a jab at the matplotlib team.
>
I had tried to work things out so mpl would only install traits if traits
wasn't already installed, or if the installed version had also been provided
by mpl. That turned out to be insufficient to avoid the problems you and
Gael had to deal with, because if setup.py was ever run when Traits was not
installed, distutils would copy traits into the build/ directory. Once it
ended up in build/, "setup.py install" would install it regardless of what
checks were in place in setup.py, thus overwriting existing Traits and
breaking environments.
To make a long story short, it won't happen again.
Darren

On 2009年05月18日 20:05, Darren Dale wrote:
> On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...
> <mailto:rob...@gm...>> wrote:
>
> On 2009年05月18日 19:07, Andrew Straw wrote:
> > I've been hacking away at adding support for "dropped spines" to MPL
> > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> > have come to the conclusion that there is a fundamental issue in the
> > code base that the traits package has solved -- many values that
> depend
> > on other values with complicated stuff that happens when one of the
> > parent values changes. For example, the location of the text from the
> > xaxis depends on the padding value in addition to the xaxis location.
> > Now I'm trying to add another element to the mix -- namely an
> axis spine
> > that can change location -- and things are going to spiral into a
> > (further) collection of special-cased updates unless there's some
> > reworking of the infrastructure.
> >
> > So, the question is, should I attempt to use traits for this? I guess
> > that I won't have the time to re-write the entire code base to use
> > traits, but I'd like make a stab a stab at dropped spine support with
> > the knowledge that, should I be successful, there's at least a
> chance we
> > would again ship traits with MPL. I imagine we could
> incrementally move
> > more and more to traits if I'm successful, particularly now that
> we have
> > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include
> the code in
> matplotlib itself, stick it under matplotlib's namespace.
>
>
> We stopped shipping traits with mpl a long time ago, when that issue was
> identified.
But part of that calculation was that Traits wasn't being used for anything 
non-experimental. Since that is being revisited, and since you still do 
distribute other packages like dateutils and pytz (which also cause similar 
installation headaches) the same way, I would like this to be kept in mind.
> I really don't want to
> go back to having to fix people's broken installations again.
>
>
> Was that comment really necessary?
Was it really offensive? People would install matplotlib, then they would try to 
install other parts of ETS, the ETS stuff wouldn't work, thus they had a broken 
installation. I do not want to go back to having to fix their broken 
installations. This isn't a jab at the matplotlib team.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...> wrote:
> On 2009年05月18日 19:07, Andrew Straw wrote:
> > I've been hacking away at adding support for "dropped spines" to MPL
> > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> > have come to the conclusion that there is a fundamental issue in the
> > code base that the traits package has solved -- many values that depend
> > on other values with complicated stuff that happens when one of the
> > parent values changes. For example, the location of the text from the
> > xaxis depends on the padding value in addition to the xaxis location.
> > Now I'm trying to add another element to the mix -- namely an axis spine
> > that can change location -- and things are going to spiral into a
> > (further) collection of special-cased updates unless there's some
> > reworking of the infrastructure.
> >
> > So, the question is, should I attempt to use traits for this? I guess
> > that I won't have the time to re-write the entire code base to use
> > traits, but I'd like make a stab a stab at dropped spine support with
> > the knowledge that, should I be successful, there's at least a chance we
> > would again ship traits with MPL. I imagine we could incrementally move
> > more and more to traits if I'm successful, particularly now that we have
> > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include the
> code in
> matplotlib itself, stick it under matplotlib's namespace.
We stopped shipping traits with mpl a long time ago, when that issue was
identified.
> I really don't want to
> go back to having to fix people's broken installations again.
>
Was that comment really necessary?
Darren

On 2009年05月18日 19:07, Andrew Straw wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
If you do, *please* either depend on Traits or, if you must include the code in 
matplotlib itself, stick it under matplotlib's namespace. I really don't want to 
go back to having to fix people's broken installations again.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Hi Andrew,
On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <str...@as...> wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>
A couple summers back I wrote the config subpackage for mpl, which is based
on Fernando's traited configobj package TConfig. It hasn't been used or
tested in a while, but the other devs had been pretty good about keeping it
up to date with changes to the regular rcparams. If there is any push to use
Traits in mpl, I would really like to see the config package ressurrected.
To use it, there is a global variable in matplotlib's __init__.py that needs
to be set to True.
Darren

If you switch to traits, will things still build with py2exe? Are there
speed costs? Startup time?
Cheers,
William
On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <str...@as...> wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.
So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).
-Andrew