Re: OF: community packages depending on external packages?

[PhilipNienhuis]

Olaf Till-2 wrote
> Hi,
> 
> in recent package release submissions, the issue came up whether
> OF packages in the "community" category should be allowed to depend on
> packages in the "external" community.
> 
> I think not. The "community" category was meant for a tight connection
> with the development of core Octave. For this, our developer community
> was meant to have control over the "community" packages. This control
> is necessary, among others, for namespace issues.
> 
> "External" packages, on the other hand, are under the sole control of
> their individual maintainers. Sometimes, they indirectly depend on
> m-code developed only for Matlab.
> 
> If "community" packages depend on "external" packages, they depend on
> m-code which is not under the cotrol of our developer community. I
> think this would be a mistake.

Thanks for bringing this up on the maintainers ML, Olaf.

There was a previous discussion, initially confined to the package release
tracker for geometry-4.0.0 and its dependence on the matgeom package (in
turn depending on a matgeom toolbox). Now that gets a wider audience, which
IMO is good. I think it would also be good to bring up that discussion,
starting here:
https://sourceforge.net/p/octave/package-releases/376/#cba1

While theoretically you might be right, I think from a more practical POV
this interpretation may lead to less enthusiasm and maybe even frustration
for existing and potential OF package maintainers, including myself.

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).
On the plus side, I could then stop nitpicking about Octave coding style for
contributed functions on the patch tracker, and such a change surely would
help speed up development.

Looking at some external OF packages with your reasoning in mind, e.g.,
octproj and octclip, I wonder why those are external in the first place. 
Conversely, the (community) video package depends on a very specific
external library maintained by a third party (= not under our control).

As to namespaces, AFAIK the Matlab / Octave language doesn't have that
(yet?) so I suppose that point is moot.

Anyway, it is too bad that this subject, dependence on external packages,
wasn't touched in sufficient detail during the discussion about community
and external packages some years ago.

Philip




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