octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pkg.m] Load order of dependencies


From: PhilipNienhuis
Subject: Re: [pkg.m] Load order of dependencies
Date: Tue, 10 Dec 2019 10:57:13 -0600 (CST)

apjanke-floss wrote
> On 12/9/19 3:39 PM, PhilipNienhuis wrote:> JuanPi wrote
>>> Hi all,
>>>
>>> Is there any reason to make pkg.m load first the package and then the
>>> dependencies?
>>
>> I had more or less similar questions about pkg.m, motivated by matgeom /
>> geometry as well, but some years ago also by rad2deg & deg2rad that
> happened
>> to live in two different OF packages and later on in core Octave as well.
>>
>> The logic is in scripts/pkg/private/load_packages_and_dependencies.m
>> As far as I could follow that code there is no need for a specific
> order of
>> loading of packages. AFAICS the order in which package and dependency
>> directories are added to the path is just a corollary of the way the code
>> happened to be written.
>> But I can be wrong ....
>>
>> Lately I did some work on pkg.m so I got some feeling for how it sticks
>> together. I'll look into this but only later this week or next weekend.
>>
>> Philip
> 
> I would think that the dependencies of package A should be loaded before
> A, because A's startup/teardown code (in PKG_ADD or PKG_DEL) might use
> functions/classes provided by its dependencies?

Sure, that feels like the obvious. But pkg.m as it stands just doesn't work
that way.

Moreover, dependencies aren't always so "linear".
ISTR there were (or are?) circular dependencies. Or mutual exclusive
dependencies (example: package A depends on release "X" of package B, but
package C won't work with release "X" and depends on another release of B). 
And maybe someone loaded package D that also depends on package C and thus
implicitly loaded it, and now wants to also use package A. What should pkg.m
do then?
In short, there could be an almost infinite number of scenario's for
interdependencies that all need to be catered for (if only by informing
users of incompatibilities) in a proper package management system.
IMO the "-nodeps" flag is a rough but indispensable escape to somehow deal
with this.

Anyway, from what I learned recently when I dived in pkg.m, it is quite a
cleverly written piece of code, but apparently it never got completely
polished. Several small gotchas and corner case issues are still hidden here
and there. My guess is that the cause lies partly in the complexity I
touched upon above.

As to the problem at hand:
AFAICS (but correct me if I'm wrong) "loading" a package involves nothing
more than just adding its code directories (.m, .oct/.mex) to the path.
PKG_ADD code automatically takes care of the package init scripts.
So, this whole issue of JuanPi it is really just about the order in which
package directories *happen* to be added to the path.
Now, load_packages_and_directories.m first adds the directory of a package
to that list and only then dives in the dependencies and adds them one by
one, if needed recursively if dependencies themselves also happen to have
dependencies, and so on.  So *I think* merely reversing the final list
before handing it to the code that adds the package dirs to the path would
solve it in one fell swoop, so to say.
Again, I could be wrong - it just needs to be tried and I only have time for
that later this week or weekend.

Philip




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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]