installed. Is this recommended? (I understood that some packages are
>
> Hi
>
> Thanks all for the comments, specially Oliver, you understood my
> problem pretty well.
> To solve this issue as soon as possible i will go like this.
>
> 1. I do have a way to create a installable matgeom package, hence
> geometry can depend on a given version of matgeom. I can add a PKG_ADD
> directive in the geometry package to check the installed version of
> matgeom.
> 2. I need to find a place to host the matgeom tar file. If we are
> bundling non-OF-compliant code with distributions, can we not also
> host non-OF-compliant needed packages, like this case?
> I see the following advantages: 1.Adds modularity to the package
> development. 2. Packages with this "external dependencies" get
> simpler, i.e. simpler makefile, configure scripts, etc... 3. Several
> packages with same external dependency do not duplicate code (i.e.
> smaller worst case tar files). What are the cons here?
> I can foresee resistance to follow this path due to the "how to
> avoid these other boderline cases", but i can imagine, if we accept
> bundled code, how this can be different. I guess we will also get
> complaints about reproducibility of installation of older versions,
> which is solved by keeping older tar of the external dep.
> If OF wont host the external dep matgeom (package, not repo), any
> recommendations where to do it? SF? Bitbucket? Somewhere else?
>
> Thanks
> On Wed, Aug 15, 2018 at 9:41 PM Oliver Heimlich <
[hidden email]> wrote:
> >
> >
> >
> > Am 14. August 2018 00:00:02 MESZ schrieb Juan Pablo Carbajal <
[hidden email]>:
> > >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