Re: [OF geometry] un-syncable with upstreeam

[Philip Nienhuis]

hi JuanPi,

Juan Pablo Carbajal wrote:
> 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
> 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.
> 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?
>
> 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?

AFAICS the underlying question is:
"Is it acceptable for an OF package to depend on an external package?",
right?
Because this is gonna happen either way as far as OF-mapping goes: 
either mapping depends on an external geometry, or mapping depends on OF 
geometry that depends on external matgeom.

At the very moment the decision was made (AFAIR with fairly good reason) 
to have OF packages an external packages, I already figured there would 
be corner cases; simply because every sort of "yes/no" or "in/out" 
distinction inevitably brings those along.

My stance, from a practical POV, would be to just include matgeom as-is 
in a subdir (probably with some hierarchy inside) of an OF geometry 
package so that it can be somehow marked "external". As long as all 
functions are documented and have copyright + license info I suppose 
we're okay (that could be just some awk script or even sed).
There are already some wrapper functions linking to the matgeom 
functions anyway.
Perhaps doumentation may need a bit of thinking over, but there already 
is some, or even all docs.

TTBOMK there are existing examples: external gdalread.cc in 
mapping/src/, slicot in control, clipperlib in geometry/src/, .... all 
of which may or may not comply to formal OF standards.

HTH
Philip