On 10/19/2013 04:14 AM, Ian Thomas wrote:
On 18 October 2013 19:18, Chris Barker <chris.bar...@noaa.gov
<mailto:chris.bar...@noaa.gov>> wrote:
Ian,
> I am working on a PR to replace the use of matplotlib.delaunay
with the
> Qhull library.
nice! -- ( though I sure wish Qhull did constrained delaunay...)
> Installation will be similar to the existing packages LibAgg
> and CXX in that if the system already has a sufficiently recent
version of
> Qhull installed then matplotlib will use that, otherwise it will
build the
> required library from the source code shipped with matplotlib.
Why bother, why not just always build the internal version?
(for that matter, same with agg)
Wouldn't it be a lot easier and more robust to be sure that everyone
is running the exact same code?
What are the odds that folks are using qhull for something else, and
even more to the point, what are the odds that the duplication of this
lib would matter one wit?
This isn't like LAPACK, where folks have a compellling reason to run a
particular version.
-- just my thoughts on how to keep things simpler.
Chris,
Todd has hit the nail on the head.
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. 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, and it will build OK
without any further changes and we can all be confident that it will
work correctly.
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.
Agreed on all of these points, and I'm not advocating a change from what
Ian is doing. However, as get on in years, I'm starting to more and
more feel like 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... Anyway, just food for thought. I still think
the most practical approach is the one we're taking (shipping
dependencies, but making it easy to use the system libraries when
available).
Mike
--
_
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com
------------------------------------------------------------------------------
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
