[Octave-bug-tracker] [bug #57522] "pkg unload" does not care for dependencies

[Philip Nienhuis]

Follow-up Comment #10, bug #57522 (project octave):

Dear JuanPi:
When you call "pkg load",  pkg.m calls its private function load_packages,
which in turn calls "load_packages_and_dependencies.m", and in the latter's
subfunction "load_package-dirs" on L. 73 you'll see an "if (handle_deps)"
if-clause that determines whether the dependencies will be involved.
So the "-nodeps" functionality for "pkg load" is implemented and works; you
can easily verify yourself by trying :-)  The fact that it is undocumented is,
well, just the next bug; ATM I have spotted about 4 or 5 other pkg.m bugs
awaiting sufficient investigation to enter meaningful bug reports; on top of a
few I have submitted patches for that are awaiting review.
(BTW I never intended to get drowned in pkg.m bug fixing, honestly :-) )

As to the coding style, I'm probably spoiled by having been exposed too much
to kludgy code from interns, some colleagues, etc. :-) (and maybe from myself
too)

I do agree that the pkg.m code itself could be improved. E.g., for loops where
a cellfun() would do the job better (and avoids debug-stepping through that
loop for all 47 packages in the Windows installer); no descriptions of how the
private functions are supposed to do what, other than their name; the fact
that for many tiny actions the entire installed package databases (local and
global) need to be re-read by installed_packages.m and again morphed into
something that's easier processed (a big waste of resources IMO); and so on.
As you say, such issues make it hard to find hooks to improve and extend the
code, let alone fix bugs.
That said, I think the structure and organization of pkg.m aren't so bad in
comparison.

The Pareto principle was probably at work here. My impression is that pkg.m
was finished for 80 % and then left alone. You and I know that getting that
far probably took 20 % of the time, and polishing the rest would have required
the other 80 % but that never happened.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57522>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/