As I never found (or perhaps I never search for it enough) a good article about how to manage the init.m files, I ended up developing my own “standard”, but I wonder how bad I did it.
For example, my usual init.m is stored in C:\Documents and Settings\All Users\Application Data\Mathematica\Kernel\init.m (Windows) and I edit it using a text editor.
As I don’t want the definitions to go into the Global context, the content is something like:
(** User Mathematica initialization file **)
Begin["MyInitContext`"];
Cl:=Clear["Global`*"];
(* Other definitions in this Context *)
End[]; (* End Context *)
$ContextPath = Prepend[$ContextPath,"MyInitContext`"];
I don’t load packages from the init.m, because I want strict control over what I load, so I only define here shortcuts to utility functions I use on a daily basis and some options.
So: Any references to good practices? Better ways to achieve this kind of behavior? Any caveats?
Firstly, I would strongly recommend against putting anything significant
init.m, since this invariably results in old stuff being broken when you come back to it after a few years. Much better to put your customizations on the path so you can quickly load it at the head of each notebook: That way the context is explicitly stated and you can easily change versions without breaking old stuff.My current setup is to start with
Needs["Janus`"]where theJanusdirectory has a custominit.mfile that loads every file in the directory into the context. This means I can add utility functions in each their own file like this one (clear_cache.m):Here is the file
Janus/init.m. Note that it prints out the name of the loaded extensions, all in the spirit of keeping the context explicit without too much hassle.