Re: [matplotlib-devel] Directories for C/C++ extensions

[Todd <tod...@gm...>]

On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker <chr...@no...> 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.