On Mon, May 18, 2009 at 9:37 PM, Robert Kern <robert.k...@gmail.com> wrote:
> 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?
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
------------------------------------------------------------------------------
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
