Re: [pkg.m] Load order of dependencies

[Kai Torben Ohlhus]

Dear all,

Since following the work on GNU Octave in 2013, I always notice a high
tension when it comes to the pkg implementation and the organization of
Octave Forge itself.  My humble perspective is, that the current
implementations do a good enough job so far and there is lack of
maintenance power in both Octave Forge and the pkg tool, which might
stress developers as well, who spend time and effort in improvements:

On 12/10/19 5:39 AM, PhilipNienhuis wrote:
> Lately I did some work on pkg.m so I got some feeling for how it
sticks together.

On 12/10/19 5:45 AM, Andrew Janke wrote:
> Also, anybody who cares about this, come on by Packajoozle and give
> suggestions if you want. https://github.com/apjanke/octave-packajoozle
> Packajoozle loads its packages in dependency order (dependents before
> dependers) for this reason.


The original question by Juan was for the scenario:

   A depends on {B depends on {D, E}, C}

if the loading order by pkg should be (and in pkj is)

   1. Load {D, E} undetermined order; functions to top of loadpath
   2. Load {B, C} undetermined order; functions to top of loadpath
   3. Load A                        ; functions to top of loadpath

but the exact opposite seems to be implemented in pkg, right?  To me the
stated order above seems more "natural" as well.

On 12/12/19 10:26 AM, Juan Pablo Carbajal wrote:
> As said many times pkg.m should be replaced [...] I am not convinced
> pkj does a much better job, but it at least enjoys a more maintainable
> structure.

@Juan, did you use pkj and can confirm that it cannot handle your
loading issue?  The dependency between geometry [1] and matgeom [2] will
occur in the upcoming release [3], right?


The next aspect that came as an argument for the current pkg implementation:

On 12/11/19 1:57 AM, PhilipNienhuis wrote:
> Moreover, dependencies aren't always so "linear". ISTR there were
> (or are?) circular dependencies.

Is this really somewhere the case, or theoretical consideration?
Personally, I agree with Andrew in this respect:

On 12/11/19 5:55 AM, Andrew Janke wrote:
> Circular dependencies; ouch.

Thus I would not stress this, if it is an exceptional/non-occuring case
in current OF packages.

@Philip, do you currently spend effort in improving the current pkg
function, or should pkj by Andrew be a favorable long term replacement?
 Agreeing on this might save time and effort.

@Andrew, what is the state of pkj?  Would you say it can be merged to
core Octave?

Best,
Kai

[1]: https://octave.sourceforge.io/geometry/index.html
[2]: https://github.com/mattools/matGeom
[3]: https://sourceforge.net/p/octave/geometry/ci/default/tree/DESCRIPTION