> To expand slightly, with the current situation the onus is on us to ensure > that mpl builds OK and passes all of our tests with and without each of the > external libraries.
If you only have internal libs, then there is less to do -- it only need to work with the version you bundle. And making sure it works with any-old-version-that-may-not-exist-yet is a pretty formidable challenge! > Linux distro packagers will choose to set up qhull as a > required dependency for their mpl package, and once they have done this can > simply delete our directory containing the qhull source code in their mpl > source package, If they are going to insist on doing this, then, yes you should certainly do it this way. > we can all be confident that it will work correctly. only if you've tested against the version (maybe patched) of the external lib they are using... > If we always used our internal version then distro packagers would have to > change our setup scripts to build using the external libraries. This would > be more time-consuming and error prone leading to less timely mpl distro > releases. We need to make their job as easy as possible. it's easiest for them if they don't try to pull out an included dependency -- but maybe you're right that that REALLY want to do that! >The needs of the distro packagers, which are primarily security and > stability, are sometimes at odds with the needs of scientific software, > where the premium is on reproducibility. The output of matplotlib depends > on the versions of some of its dependencies, not the version of matplotlib > alone, and that's problematic for some... exactly -- if we know exactly which version of a lib is in use, we know that it works the way we expect in the use cases we expect to use it in. But I'm not maintaining this code, so have at it in the way that makes sense to you. NOTE: it would be a different story if this were a netwroking protocol lib, or something where security patches would be critical. Maybe I'm naive, but this doesn't seem likely in this case. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
