On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote: > Eric Firing wrote: > > Dave Peterson wrote: > >> That said, given the upcoming release of Traits 3 this situation may > >> get a little crazier. T2 and T3 are not fully api compatible, though > >> they are very close. So I suspect version numbers are going to play > >> a larger role in the future. Is there anything we can do in the T3 > >> release to make resolution of this upcoming issue easier to deal with > >> for the matplotlib team? One point probably worth mentioning is > >> that, IIRC, we currently rely on T3 being installed with egg > >> meta-data in order to determine an accurate version number. > > > > Whether, or to what extent, mpl starts depending on traits is still > > open; but if we do depend on it, I think we should simply require T3 > > as an external dependency. If that requires some slight modifications > > of Darren's code, which was written for T2, I expect the changes will > > be easy.
I think T2->T3 would not be a difficult transition for us. It may not even require any modifications, I seem to remember the traited config stuff just worked with traits3 last time I tried it, I just dont remember when I tried it last. > > Three questions: > > > > 1) To what extent would the range of T3 eggs cover the various > > platforms on which people run mpl? > > Not quite sure on this one as I don't know what platforms are most used > by mpl. What I can say is that we've worked very hard to minimize the > dependencies Traits has on other things in order to make it as easy as > possible for people to install. We'll definitely be uploading a source > tarball, which should meet most people's needs, and a Windows binary > (since not all users there have a c compiler.) We may or may not put up > OS X, and a couple linux distribution, binaries. > > > 2) For uncovered cases, should T3 be easy to build and install? > > T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the > backend projects seem to be pure-python though clearly you'll need libs > for the chosen backend. > > > 3) My recollection is that setuptools was determined to be causing a > > hit to the startup time, and mpl is already sluggish in starting up. > > Is there any more insight or progress on this front? Is there a way > > to use traits in mpl without increasing the startup time? > > I'm not sure it was setuptools' egg features that were the problem so > much as I thought it was the use of namespace packaging we have embedded > all over in ETS. I don't see any significant efforts underway at this > time that are trying to speed this up, but perhaps I'm just uninformed > about any such efforts. I don't see anything on the horizon that would > let us remove this from the ETS projects either. The end result is I > don't see any way mpl could work around this and still treat Traits as > an external dependency. Fernando saw a big performance hit due to namespace packaging, but I never saw it. I think we concluded that the presence of large NFS mounts were causing the performance hit in namespace packages that Fernando reported at Scipy last year (Dave, was it you who worked with him?). I did some profiling a while back also, after we added traits to the mpl codebase and stripped out the namespace packaging. We still saw something like a 30% performance hit, which I tracked back to regular expressions being compiled in traits and in configobj. See: http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989 Darren ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
