Not all packages can be loaded on startup. There are some operations that simply do not work during startup, the most prominent one being Throw
/Catch
.
For this reason, it is generally not a good idea to load packages on startup.
See my questions about this here:
These came up while I was trying to make my own packages "init-resistant".
What can you do to avoid the problem?
What can you do then?
You can use @WReach's suggestion from the post I linked. Load the package in a scheduled task:
RunScheduledTask[
(* perform some complex initialization *)
; RemoveScheduledTask @ $ScheduledTask
, {0}
]
This did not work for me unless I set a non-zero value for the delay. It did work when I set it to 1 second.
But I am not comfortable with this solution. What if the kernel startup is triggered by evaluating a cell which has code that relies on the package you are loading?
Aside: I have also seen it many times that starting up the kernel by evaluating certain cells will trigger crashes or other misbehaviour sometimes. This was affecting some of my notebooks when I was using version 8 on a not very fast computer. Since then I did not encounter this frequently, though 11.1 tends to randomly start up very slowly for me when kernel start is triggered by cell initialization. I have no proof, but all these problems could be explained by such scheduled tasks ... if such things are used internally within Mathematica. I am just guessing that this might be related to scheduled tasks, and I am probably wrong. Do not take it too seriously.
Another thing you can do is use DeclarePackage
and list every symbol in that package. Then the package will load only when you actually use something from it.
What can the package author do to avoid the problem?
The best solution would be to ask the person who wrote the package to make it init-friendly. I wrote about how to do this here:
For most packages this is easy. For others, not so much.
Throw
,Break
, and the like. These do not work during loading. $\endgroup$