From: Dave P. <dpe...@en...> - 2008-06-09 18:55:37
|
Gael Varoquaux wrote: > On Mon, Jun 09, 2008 at 12:04:58PM -0400, Darren Dale wrote: > >> Gael, maybe the following situation caused the trouble: >> > > >> 1) user downloads mpl source >> 2) builds matplotlib - traits now exists in the temproary build directory >> 3) installs enthought traits >> 4) installs matplotlib - traits would not have been built in this case, its >> already installed on the system, but it still exists in the build directory >> and gets installed anyway. >> > > Actually, after looking at the code and thinking a bit more, I think the > problem might simply be with different version of traits installed in > different directories in the sys.path, with Python's import mechanism > picking up the MPL-installed one, rather then the user-installed one. > Tricky problems that I see more and more happenning. > > But I don't have an example box to test this hypothesis, so we are still > clueless. > In my experience, the current method really only falls down for those trying to publish binary distributions who don't realize the potential consequences of this build-time detection, or that there is even a decision being made there about the content of what is being built. Say, perhaps those building EPD. :-) Luckily, once you know what is going on during the build, it's a pretty easy problem to solve. 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. -- Dave |