On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker <chris.bar...@noaa.gov> wrote:
> > 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!
>
We have sonums for this very reason. And this could apply just as well to
python itself. There is a reason not many distros ship SAGE packages.
> > 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.
>
Yes, they are. This is the whole point of having packages in the first
place, as opposed to something like windows where every program just
bundles everything..
> > 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...
>
It is only matplotlib's responsibility to test against the unpatched
versions specified, just like it is only matplotlib's responsibility to
test against the unpatched python versions specified. Doing this isn't a
particularly difficult task, there are easily tens of thousands of apps
that have no problem with this.
> > 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!
>
It would be easiest if matplotlib detected whether the library is present
at build-time. That is what most packages do.
> >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.
>
You would be surprised what sort of packages can lead to security
vulnerabilities.
------------------------------------------------------------------------------
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=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
