Re: [pkg.m] Load order of dependencies

[PhilipNienhuis]

Hi JuanPi:


JuanPi wrote
> Hi all,
> 
> Is there any reason to make pkg.m load first the package and then the
> dependencies?
> 
> Taking the development version of geometry as an example:
> 
>> pkg load geometry
> GEOMETRY
> matgeom loaded 0
> MATGEOM
> geometry loaded 1
> 
> For me it would make only sense that at the time the package folder is
> added to the path the dependencies are already loaded.
> 
> This would simplify enormously checking for functionality in the
> dependencies and manipulating the loadpath at loading time.
> 
> Also, if we allow packages to shadow octave functions, then packages
> should also be allowed to shadow other dependencies functions, that is
> the package must load at the end of all dependencies.

OK, I looked into it and my conclusions are as follows:

1. There is a subtle but deceiving difference between "loading" a package
and the effects of adding its directories to the path.
The earlier a package is loaded, the lower its directories show up in the
path. IOW, packages "loaded" later are searched earlier in the path.

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.

3. But what you want to accomplish is exactly the opposite. You want that to
make sure that functions in some package can shadow similarly named
functions in its dependencies.

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.

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.

* Technically:
Adapting pkg.m to first load dependencies and only then the desired package,
if so desired for some package, is surely possible.
But the story is more convoluted: just think of the possibility that one of
the dependencies *does* need another dependency for its initialization so
needs that dependency earlier in the path (= loaded later).
The implication is that the whole thing is going to be relying on the needs
of individual packages and cannot be catched in e.g., another flag for
pkg.m.
The most reliable way to get it together would be to add another field to
the package DESCRIPTION file or amend the "Depends" field to indicate how
some package wants to deal with each of its individual dependencies. That
has to be done in such a way that all currently existing packages aren't
affected.
I fear that is going to be a big headache at this moment.

Now as regards matgeom and geometry:
* matgeom is a dependency of geometry
* matgeom has been split from geometry for several reasons, mostly for ease
of upgrading geometry and matgeom separately, (IIRC) license stuff,
perceptions regarding external or community packages.
* nevertheless geometry and matgeom are heavily interdependent.
I suppose matgeom and geometry won't be used much separately.
Taking this into account, for the time being I'd advise to simply remove the
offending functions in matgeom (or rename them).
Maybe that can be done in some init script in the geometry package that
checks if matgeom is installed (should be as it's a dependency of geometry)
and if so, processes the pertinent matgeom function files. Hopefully that
won't give trouble, as this will rename a file actually in the search path
(cached?).

In view of this it's a bit of a pity that the post_install.m file in package
root dirs has been dropped. It would have offered an ideal option to deal
with these sort of issues.

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html