Re: [OF geometry] un-syncable with upstreeam

[Oliver Heimlich]

Am 14. August 2018 00:00:02 MESZ schrieb Juan Pablo Carbajal <address@hidden>:
>Hi Phillip, Of leaders, and maintainers,
>
>I was trying to release geometry today. It is impossible! (well very
>hard).
>The problem is that from the beginning I made the mistake of trying to
>convert the package to Octave and Of standards... wrong!
>
>So I am inclined to:
>1. Reduce the current geometry package to contain only our extensions
>to matgeom
>2. Put 3rd party geometry code into matgeom package (which will just
>package what comes from matgeom developers)
>3. mapping will have to depend on geometry, which in turns depends on
>matgeom

Hi Juan,

thank you for trying to convert the matgeom package into our coding standards. 
Apparently, the lesson learned is, that this approach is not maintainable while 
upstream is still actively under development. 

I agree that a third party matgeom package sounds like a good solution.


>Now the BIG issue with this:
>The reason I tried to convert matgeom to octave standard was to be
>able to include the package in OF. This is currently a nightmare!
>So by making an Octave package matgeom that can be easily synched with
>upstream, I will have to abandon Octave and OF standards and matgeom
>wont be hosted in OF anymore cause it will be not compliant.

Yes, the third party matgeom package, which mostly contains the upstream 
contents, would not be a candidate to be hosted on OF as an individual package.

>This means installation of packages that depend on matgeom wont be
>automatic, e.g.
>pkg install -forge geometry
>will always fail due to missing dependency matgeom.
>
>What to do in this scenario?

I can think of two possible solutions. You could check for the presence of 
matgeom during package installation of geometry. For example, in a configure 
script or Makefile. Or during runtime, where you have more options to query the 
user.

 1. If matgeom is missing, there could be an error message with instructions to 
download the third party dependency from elsewhere. Octave can 'pkg install' 
from external URLs since version 4.4.0, so it could be possible to offer 
automatic download and installation / let the user copy and paste the required 
command.

2. The third party dependency could be bundled in the release tarball of 
geometry to be installed if needed. We also bundle third party C libraries 
which don't match our coding style, so I see no problem in bundling a third 
party Octave package.

Both approaches overcome the installation problem for the user. However, you 
have to worry about more things to not produce new problems:

A) The matgeom package won't receive updates. How should a case be handled when 
an old matgeom version is already installed, but geometry needs a newer version?

B) Should a missing matgeom dependency be installed automatically? Should there 
be a query which the user can acknowledge?

C) Can/should we publish documentation for matgeom functions on OF as part of 
geometry's function reference? Probably not, if I understand correctly how you 
want to utilize matgeom.

>One alternative I see is to fork only what our extensions actually
>need from matgeom and put those in geometry in a OF complaint form
>(definitely diverging from matgeom). Beware! This is not minor amount
>of functions, and to do it in a reasonable time I will need help.
>
>Is this scenario better?

To me, this doesn't sound more maintainable than your initial approach. I'd 
recommend against it.

Oliver