Why do that rather than suggest DisplayPackageLoadingLog?

Unless I am missing something, DisplayPackageLoadingLog does not help on its own:

gap> LoadPackage("openmath");
#I  OpenMath package is not available. To see further details, enter
#I  SetInfoLevel(InfoPackageLoading,4); and try to load the package again.
fail
gap> DisplayPackageLoadingLog();
#I  Carat: Carat binaries must be compiled
gap> SetInfoLevel(InfoPackageLoading,4); 
gap> DisplayPackageLoadingLog();
#I  Carat: Carat binaries must be compiled

Why not display the full failure log as a default, or at least an actual error message, for instance the fact that io is not available above, and maybe even the reason why?

@markuspf No fundamental reason, but extreme care is needed to present the right information. To decide what information is "right" you need a global overview of the package dependency/suggestion graph and of all the failures before you can start. Remember that the graph is not a tree (it's not even a DAG) so you have to distinguish packages which are connected to the users original request by a path consisting entirely of "needed" relations from one where there is always a "suggested" relation somewhere in the path. You do not want to print messages about the latter.

Incidentally, is level 4 the right level. Usually level 3 is all that is needed to get relevant Info messages for anyone but the author of the code.

Mhm. Maybe just setting InfoPackageLoading to 3 after autoloading is finished would be sufficient. After all the problem we are trying to solve is that the ephemeral "user" tries to run LoadPackage("xyz"); and just gets fail, and that problem is addressed this way. Also we can provide a means for advanced users to change this behaviour back so that they are not bothered by verboseness.

I always call DisplayPackageLoadingLog anyway after I get a failed package load, so this change would save me the typing at least ;).

What you don't want is

gap> LoadPackage("xyz");
#I pqr: Can't load for some reason
true

which can happen if pqr is suggested by xyz. On the other hand, if you try to suppress this you need to be alert to the possibility that pqr is also needed by abc which is needed by xyz.

There are various possible small improvements but the "right" answer IMHO: is

1. make sure that all InfoPackageLoading messages get logged -- actually why don't we log ALL info messages globally? We can always start dumping old or low-priority message after the log gets to 64MB or something.
2. write a function which analyzes the log after a failed package load and actually identifies the reason(s) taking proper account of all the weird possibilities.
3. either print the output of this after a failed package load, or print a short message explaining how to get it.

Nothing short of this is really going to work reliably.

One alternative option -- after loading failed, try loading the package again, ignoring all suggestions -- that should still fail, and will give a hopefully "minimal" explanation. It would mean that packages appear to mysteriously get loaded twice.

@markuspf: But if you will just set InfoPackageLoading to 3 then it will increase the verbosity also in the cases when the package is available, for example:

gap> SetInfoLevel(InfoPackageLoading,3);
gap> LoadPackage("nq");
#I  nq: PackageAvailabilityInfo for version 2.5.3
#I  nq: PackageAvailabilityInfo: version 2.5.3 is available
Loading nq 2.5.3 (Nilpotent Quotient Algorithm)
  by Werner Nickel
  maintained by Max Horn (max.horn@math.uni-giessen.de)
true

OTOH, my PR displays extra messages only in the case when loading package fails.

@stevelinton: sometimes, InfoPackageLoading is not enough, for example:

gap> SetInfoLevel(InfoPackageLoading,3);
gap> LoadPackage("nq");
fail
gap> SetInfoLevel(InfoPackageLoading,4);
gap> LoadPackage("nq");
#I  nq: no package with this name is installed, return 'fail'
fail

Moreover, my PR does not improve how the NQ package is handled. I should commit another change to LoadPackage after the comment # Return 'fail' if this package is not installed. to fix this.

Urgh. So as a proposition let's merge the original PR with @alex-konovalov's improvements coming up.

The improvements that @stevelinton suggests we should keep around, maybe in an issue as something to hack on for later.

Regarding the NQ package - the case from above happened because NQ package was missing in that GAP installation. So I've now committed an extra info message which produces the following output:

gap> LoadPackage("nq");
#I  nq package is not available
#I  Check that the package name is correct and it is located in the 'pkg'
#I  subdirectory of your GAP installation or in the 'pkg' subdirectory
#I  of at least one of the directories given by 'GAPInfo.RootPaths'
fail

Indeed, in this case there is no point to suggest SetInfoLevel(InfoPackageLoading,4) since it will not tell the user anything new.

I suggest that we do merge this PR since it improves the situation, and keep @stevelinton's suggestions for the time when we will make a larger refactoring of the package loading mechanism.

I would suggest that the message when a package is simply not present (a fairly common error for instance when you mistype a package name) should be less than 4 lines. It can refer to documentation if necessary.

@stevelinton what about this:

gap> LoadPackage("somerandomlongname");
#I  somerandomlongname package is not available. Check that the name is correct
#I  and it is present in one of the GAP root directories (see '??RootPaths')
fail

Much better.

Steve

On 28 Mar 2016, at 14:49, Alexander Konovalov notifications@github.com wrote:

@stevelinton what about this:

gap> LoadPackage("somerandomlongname");
#I somerandomlongname package is not available. Check that the name is correct
#I and it is present in one of the GAP root directories (see '??RootPaths')
fail

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub