Thanks Philip for looking into this.
As said many times pkg.m should be replaced: burn to the ground, and
reborn like the fenix.
I am not convinced pkj does a much better job, but it at least enjoys
a more maintainable structure.
2. Taking into account the contents of other posts here, pkg.m is actually
doing the exact right thing, i.e., when loading a package it first adds the
desired package directories to the path, and only then the directories of
the package dependencies, AFAICS all in the proper order. But see 4., below.
As far as I understand it , this is actually all wrong. The
dependencies should be added first and then the desired package.
Only this way the packages functions are found first.
Only then you get consistent behavior with what happens if the package
shadows an octave function (I hope we all agree octave is a dependency
of the package).
That is, you insert the latest loaded package on the top of the path.
So if you start by loading dependencies from the leaf nodes, this is
properly resolved.
But of course there might be other problems waiting hidden in that
implementation.
4. Dependency directories are at the top of the path and searched first, as
one normally would expect and desire, because of the thinking that
dependencies may be needed during initialization of the desired package.
However, the weak point in this reasoning is that it is valid for *all*
packages. Some, if not most, packages don't need dependencies for
initialization, they just need dependencies to supply functionality for them
at run time, not initialization time.
I guess it depends on the definitions here, but as of now, I do not
see any troubles in accepting that:
1. During "initialization" dependencies are available, but the package
itself isn't (call it pre_load if you want).
2. After initialization the package is actually loaded and its folders
added to the top of the search path. At this point dependencies are
shadowed if the package defines homonymous functions.
Looking at how pkg.m works, getting together point 3. above would be
difficult because of the following;
* Process:
If we adapt pkg.m, it would very probably only apply to Octave-6.1.x, and
the packages matgeom, geometry (and mapping) (the actual packages concerned
here) would depend hard on the latest version of Octave and on the latest
version of each other. I think that would be an undesirable situation.
Packages should be backward-compatible with a few older octave releases.
I do not generally agree with this, since it is only some
functionality that is lost when using older version of octave. Most of
the package still works.