Re: OF: community packages depending on external packages?

[Olaf Till]

On Wed, Sep 04, 2019 at 04:06:01PM -0500, PhilipNienhuis wrote:
> If we follow your reasoning the mapping package (depending on geometry and
> matgeom, in the future also on octproj) must become external as well, maybe
> even io as that also depends on external SW beyond our control (like Java
> libraries for spreadheet I/O other than .xlsx, .ods and .gnumeric, some of
> which are effectively abandoned now).

I think external libraries (C, Java, or Python) are a different thing,
please see below.

On Wed, Sep 04, 2019 at 02:41:06PM -0700, Mike Miller wrote:
> Can you explain why you think that depending on externally developed
> m-file functions would be unacceptable for a community package, but
> depending on externally developed C or C++ functions or programs would
> be acceptable?

I can't explain it. It's rather a basic decision on whether we want
Octave and the "community" packages to be as a group self-contained
with respect to m-code (and "oct-code") or not.

It seems clear to me that a border must be set somewhere, which I'll
try to illustrate with the following examples.

Consider the following partially speculative case: Octave has
delegated many of its much used statistics functions into the
statistics package, probably under the premise that there they still
are under control of our community. What if we decided to let these
statistics functions depend on "upstream" code developed for Matlab?

And consider this corner (?) case, too: A formal "community" package
provides only glue to incorporate an "external" package, by
explicitely depending on it. Then the "community" package is de facto
"external".

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: PGP signature