On 2009-05-18 20:05, Darren Dale wrote: > On Mon, May 18, 2009 at 8:41 PM, Robert Kern <robert.k...@gmail.com > <mailto:robert.k...@gmail.com>> 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 ------------------------------------------------------------------------------ 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
