Re: [pkg.m] Load order of dependencies

[Andrew Janke]

Thanks Kai!

On 12/11/19 9:15 PM, Kai Torben Ohlhus wrote:
> Dear all,
> 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.

One thing here: package load order and search path order are not locked
together. The addpath() function has both '-begin' and '-end' options,
so package directories could be either prependend or appended to the
path. That is, even if a dependency is loaded first, we could do so in a
manner that it ends up on the search path *after* the depender. Or vice
versa.

To me, though it seems like dependers should end up on the path before
dependencies: If package A depends on package B, that means that package
A knows about package B, and can determine which of B's functions it
should shadow. B doesn't necessarily know anything about package A.

So you could do a graph search to find a dependency-ordering solution,
load them in a dependencies-first order, but do so in a way that either
the dependers or the dependencies have priority in the path. Either as a
global policy, or on a per-package-pair basis, if that metadata were
added to the package definitions. (Which sounds like an unnecessary
complication to me, but maybe there are use cases for it?)

> 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?

If there's anything that pkj doesn't handle that y'all would like to see
supported, I'm happy to take feature requests! Just drop an issue on the
GitHub repo. My goal for pkj is to support Octave's current use cases in
a nicer manner, not to impose my view of package management on Octave.

> 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.

Well, if matgeom and geometry mutually depend on each other, then it's
unfortunately something we need to handle.

One note: I'm coming from the compiled-software world, where circular
dependencies are just a no-go. Things might be different for Octave.

> @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?

Oh no. pkj/Packajoozle is still beta at best; it is a long way off from
being high-quality or stable enough to merge to core Octave. Most
importantly, we need more testers to try it and shake out bugs and tell
us what is missing! If you'd like to see pkj become a real thing, please
drop by and try it out.

Cheers,
Andrew