Re: OF: community packages depending on external packages?

[PhilipNienhuis]

Olaf Till-2 wrote
> 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.

Ah OK, "self-contained" is the central issue. Yes that would set external
C++/Java/Python/<whatever> code & libraries apart from Octave style .m and
.oct files referencing just other Octave style .m and .oct files.
But what are the benefits of that?

When the concept of community and external packages came up (at or around
OctConf 2018 IIRC) I had the impression that it was more about a limited
collection of well-maintained packages with often used functions, versus
much more specialized -and often less actively maintained if not orphaned-
packages.
(The current community packages tally is 49 so maybe I misunderstood
"limited".)
IIRC it was also about limiting the maintenance burden of core Octave by
keeping it lean and mean. Rather than absorb functions from OF packages into
core Octave, Octave would mainly comprise general functions while more
specialized functions would live in more specialized (community) packages.
Moving many statistics functions into the statistics package is a nice
example.


> 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?

As long as the upstream licenses are compatible with the GPL and the
upstream code is well-maintained, what would be the actual problem? After
all, Octave strives to be Matlab-compatible.

We could still reverse that decision, or change to other upstream code, as
we still control that statistics package's contents. IOW we are completely
free to decide about "our" dependencies.


> 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".

Nothing would prevent the Octave community from glueing it to something
else.
I see no difference with depending on external C++/Python/Java/<whatever>
code.

In a more general sense, OF packages, whether community or external,
constitute an elegant way to link Octave to external code (hopefully of good
quality). To that end a "self-contained" concept seems unduly limiting to
me.


Philip



--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html