# Creating Mathematica packages

I'm building a package to help me write packages and their documentation. In this post I explained how to make a package and its documentation. In the answer I provided I describe how to build a very simple package. However, I have been looking around the extra packages that come with Mathematica and in some packages I see many .m files. I see this as a good way of dividing the application. Can someone describe the structure of a package?

To do this lets try to make a package out of the next simple functions. Suppose that we have the following in a notebook:

AddTwo::usage = "AddTwo[a, b] returns a+b";
AddThree::usage = "AddThree[a, b, c] returns a+b+c";
DotTwo::usage = "DotTwo[a, b] returns a*b";
DotThree::usage = "DotThree[a, b, c] returns a*b*c";
AddTwo[a_, b_] := a + b;
AddThree[a_, b_, c_] := a + b + c;
DotTwo[a_, b_] := a*b;
DotThree[a_, b_, c_] := a*b*c;


I would like to put these functions in a package. They all seem to be very simple arithmetic operations so let us make a package named SimpleArithmetic. This package is perfect to be divided into sections. One for additions and one for products, so we can make "subpackages" Addition and Product. If we follow some of the examples in the Mathematica installation we can create a folder called SimpleArithmetic in say $UserBaseDirectory. Inside SimpleArithmetic we can create two other files Addition.m and Product.m. The code for the additions would be placed in Addition.m and the code for multiplications would be placed in Product.m. The question now is, how would these files look like? There is also a folder called Kernel which contains Init.m. Could someone please just explain the best practices to create packages? I've read over the documentation and the whole "context" and "packages" keywords have already confused me. The code in the files I have described would be very appreciated. • There is no simple answer to this. In the Java world there is a tool just to create quality metrics for this topic. Read about it here: clarkware.com/software/JDepend.html. This might give you an idea of the complexity of the subject you touched. Commented Jul 9, 2011 at 7:15 • @ndroock, Is the creation of packages in Mathematica that complicated? So far I can just create a simple package, which is a collection of functions. I might be overthinking things because of the notation <<PackageName'Somethingelse' where the ' is of course . What exactly does this mean? Commented Jul 9, 2011 at 7:27 • This is a large topic. A standard reference for writing packages is "Programming in Mathematica" by Roman Maeder, 3d edition - 1996 - still very good and clear. David Wagner has a nice chapter on packages in his book ("Power programming with Mathematica - the kernel"). If you want to start with something light-weight, this answer may get you started: stackoverflow.com/questions/6633180/making-mathematica-packages/… Commented Jan 19, 2012 at 17:53 • The conventional package structure (and some of the reasoning behind it) is described in the documentation here. This won't answer your question in full, but familiarity with this is a must if you are going to develop packages. Commented Jan 19, 2012 at 18:00 • @Leonid Your comment looks like a great answer (and it has six up votes!). How about making it official? – JxB Commented Jan 20, 2012 at 8:12 ## 9 Answers Package creation is a large topic indeed. I will still attempt to give a minimal clarification of the encapsulation mechanism behind packages, since in my experience it pays off to understand it. ## What constitutes a package Basically, a piece of Mathematica code (usually containing a number of variable and function definitions), which is placed inside Begin[someContext] code End[]  can be called a package. Usually, however, at least some more structure is present. In particular, to separate interface from implementation, the typical package looks like BeginPackage[someContext] public-functions-usage-messages Begin["Private"] code End[] EndPackage[]  ## Contexts and symbol names The context here is a namespace. The convention is that context name is a string ending with "". At any given moment, the value for the current working namespace is stored in the system variable $Context, and can also be queried by calling Context[]. Begin["test"] will simply add the current context to the context stack, and then change it to "test", while End[] will exit the current context by making the previous one current.

Every symbol must belong to some context. The system commands belong to the "System" context, and the default working context for interactive FrontEnd sessions is "Global". When mma code is parsed, the symbols are given their "true" (long) names, which contain both a symbol name and a context where the symbol is. For example, Map is really SystemMap, and if I define a function f[x_]:=x^2 in the FE session, it will be Globalf. For any symbol, one can call Context[symbol] to determine the context where that symbol belongs. To "export" a symbol defined in a package, it is sufficient to simply use it in any way in the "public" part of the package, that is, before "Private" or other sub-contexts are entered. Usage messages is just one way to do it, one in principle could just write sym; and the sym would be created in the main package context just the same (although this practice is discouraged).

Every symbol can be referenced by its long name. Using the short name for a symbol is acceptable if the context where it belongs belongs to the list of contexts currently on the search path, stored in a variable $ContextPath. If there is more than one context on the $ContextPath, containing the symbol with the same short name, a symbol search ambiguity arises, which is called shadowing. This problem should be avoided, either by not loading packages with conflicting public (exported) symbols at the same time, or by referring to a symbol by its long name. I discussed this mechanics in slightly more detail in this post.

If the package has been loaded once during the work session, its functions can be accessed by their long names even if it is not currently on the $ContextPath. Typically, one would just call Needs again - if the package has been loaded already, Needs does not call Get but merely adds its context name to the $ContextPath. The internal variable $Packages contains a list of currently read in packages. ## The case at hand Here is how a package might look like: BeginPackage["SimpleArithmetic"] AddTwo::usage = "AddTwo[a, b] returns a+b"; AddThree::usage = "AddThree[a, b, c] returns a+b+c"; TimesTwo::usage = "TimesTwo[a, b] returns a*b"; TimesThree::usage = "TimesThree[a, b, c] returns a*b*c"; Begin["Private"] plus[args___] := Plus[args]; times[args___] := Times[args] AddTwo[a_, b_] := plus[a, b]; AddThree[a_, b_, c_] := plus[a, b, c]; TimesTwo[a_, b_] := times[a, b]; TimesThree[a_, b_, c_] := times[a, b, c]; End[] EndPackage[]  The functions AddTwo, AddThree, TimesTwo,TimesThree are public because these symbols were used in the public part of the package. Their long names would be then SimpleArithmeticAddTwo, SimpleArithmeticAddThree, SimpleArithmeticTimesTwo, SimpleArithmeticTimesThree. The functions plus and times are private to the package, since they are in the sub-context Private, which is not added to the ContextPath when the main package is loaded. Note that this is the only reason they are private. Should I call AppendTo[$ContextPath,SimpleArithmeticPrivate], and they'd become as "public" as the main functions (practice that should of course be discouraged by which should clarify the encapsulation mechanism).

With regards to splitting a package into several packages, this is a normal practice, but usually an individual mma package contains much more functionality than say a typical Java class, more like Java package. So, in the case at hand, I'd not split it until you get a much more functionality in it.

Of course, I only discussed here a very small subset of things related to packages. I will hopefully update this tutorial soon. An excellent reference for writing packages is a book of Roman Maeder "Programming in Mathematica". It is pretty old, but still one of the most (if not the most) useful accounts on the matter.

• thank you for taking the time to explain this important topic. I think I got this part covered. I'll be waiting for your update. What I really want is to know how to use SimpleArithmetic'Addition' and SimpleArithmetic'Product'. So far I can sort of do this but I always end up messing the links to the documentation I write. I could make everything as part of one whole package (documentation and package works) but I think it is very important to know how add subsidary packages to the application that work with the documentation. Commented Jul 9, 2011 at 9:23
• @jmlopez. Mr. Wizard's reply to this question may be of interest Commented Jul 9, 2011 at 10:49
• David Park's reply to this message is also very informative. (A new version of DP's Presentations package for Mma 8 is now available, BTW) Commented Jul 9, 2011 at 11:00
• @TomD, I think David Park's explanation is what I needed. Thank you. Commented Jul 9, 2011 at 14:18
• @TomD, I have tested what Park said, I indeed needed this piece of undocumented code in the PacletInfo.m file under Extensions: {"Kernel", "Context"->{"SimpleArithmetic'Addition'","SimpleArithmetic'Product'"}}. Now that that's resolve I can simply things by a lot. Commented Jul 9, 2011 at 14:32

I think what confuses most users who are new to packages is the larger question of where to put them and how to use them. I am going to discuss this in a larger context.

Suppose you are working on some significant or extended topic, which we will call TopicX. This topic might include many notebooks of various kinds and several packages, and perhaps later WRI style paclet documentation.

Packages are typically installed into FileNameJoin[{$UserBaseDirectory, "Applications"}] ### How to load and use a package? Evaluate << MyPack  If MyPack.m is in $Path, it will be loaded.

Now the function MyFunction is available for use.

### Notes

The description in this guide is oversimplified on purpose, to make it easy to follow. When I stated things in absolute terms, I "lied" a little bit here and there: you don't need to strictly follow this exact structure. However, this structure does represent the best practices, and going beyond it does require an understanding of contexts. The other answers here should be considered required reading after you have set up your first package.

Another thing that isn't clear from the documentation. If you want to make a .m file from .nb file, you need to change the cell properties of anything that you want in it to Initialization Cell before you save. Otherwise, the saved module file will have no active content!

• Thank you for this! I had carefully followed what seemed to be all the instructions, including copy and pasting others' code snippets. I understand why users here might not have mentioned it, but it seems that the Mathematica documentation itself might! Commented Jan 16, 2017 at 16:18

For me, the best way to create packages in based on Maeder's book. That gets things done quickly & semi ... dirtily(!) so that usages work just fine, but there's no fancy documentation center entries. The way to create such a (completely doc. center compatible package is expertly covered here.

On to the question at hand ...

If you think you need to separate functionality, then one approach is (as a template)

BeginPackage["YourPackageDirectoryYourPackageName", {"YourPackagesDependencys"}];
(* usages go here *)
Begin ["Private"];
(* Function definitions go here *)
End[]; (* private *)
(* protect what you want *)
EndPackage[];


So what you might want to do with your wrapper package is

BeginPackage[LopezSimpleArithmetic", {"LopezAddition", "LopezMultiplication"}];
Begin["Private"];
End[];
EndPackage[];


You'd then start another package like

BeginPackage["LopezAddition"];
AddThree::usage = "AddTwo[a, b, c] returns a+b+c";
Begin["Private"];
AddTwo[a_, b_] := a + b;
AddThree[a_, b_, c_] := a + b + c;
End[];
EndPackage[];


And a third along similar lines called LopezMultiplication. All packages live in \$UserAddOnsDirectory/Lopez which you'll probably need to create.

You use them by loading LopezSimpleArithmetic (Needs["LopezSimpleArithmetic"]), though you can also load individual packages for debugging.

As another guide, I'd suggest studying source code in the Statistics legacy as a complicated package with many dependencies all seamlessly resolved when you load things. Your mileage may vary.

D.

• thank you for the comment "expertly covered here". I'm a little confused about the structure of the application. Do you mean to say that we have a directory called "Lopez" which contains m files with names "SimpleArithmetic.m", "Addition.m" and "Multiplication.m"? At this moment I'm not so concerned with dependencies. All I want is to have subsidary packages (Addition and Multiplication) in the main application (SimpleArithmetic). The whole packageDirectory'subdidarypackage' is confusing at this moment. I can't find an actual example in Mathematica that uses this format. Commented Jul 9, 2011 at 9:33
• Exactly. And you can find an example that uses this format. As I suggested, the legacy statistics package is a good place to start. Have a look in MultiDescriptiveStatistics.m. This requires StatisticsCommonMultivariateCommon which is in the directory Statistics/Common.
– dwa
Commented Jul 9, 2011 at 12:30
• the problem with this legacy package is that it does not give you the file structure with the documentation. In any case, I think I got the whole file structure straighten up now. I'll be writing up another answer for the whole documentation with the plain installation of Mathematica soon and this question has helped me a lot. Commented Jul 9, 2011 at 14:39
• Very important to notice the difference between Begin["Private"] and Begin["Private"] in the above. The first one puts symbols into a single, global, Private namespace where they can collide with symbols from other packages. The second one scopes your symbols and will be critical for multi-package development, in my opinion. The wolfram site discusses only the first form here reference.wolfram.com/workbench/index.jsp?topic=/… Commented Jul 20, 2015 at 16:29

One useful approach might be to use Wolfram Workbench, if you have access to it. Whether you use Workbench or not, a good way to organise your application is to have an overarching package that calls the subsidiary packages. For example, in the large project I am developing at the moment, there is a package for general utilities (data massaging), a package for the main plotting functions (highly customised version of the usual ones), and a package that provides a more general version of one of the plotting functions (DateListBarChart). The general package calls the first two of these, and the general as well as the second package call the third. The general package could be as simple as the following. In fact, this is the main package for my application, with the acronym for my employer changed to XYZ.

(* Mathematica Package *)
(* Created by the Wolfram Workbench May 20, 2010 *)
BeginPackage["XYZ" ,{"XYZDateListBarChart","XYZXYZGraphs","XYZXYZUtilities"}]
(* Exported symbols added here with SymbolName::usage *)
Begin["Private"]
(* Implementation of the package *)
End[]
EndPackage[]


The way one organises these (for deployment) is, on Mac OS X at least, to put them in /Users/username/Library/Mathematica/Applications/. Inside this would be a folder for your main application name (e.g. XYZ), containing the main package, XYZ.m` and any subsidary packages. Documentation and Kernel are subfolders of this folder.

You might find some useful tips in Wolfram's white paper on large projects, available from this page.

• @Verbeia, I used the Wolfram Workbench to see the directory and file structure but the examples they provided were done in the most simple case. You should check out this link which TomD provided. I hope that updating Java doesn't mess with my plain mathematica installation. That's all I'm using to make the documentation. Commented Jul 9, 2011 at 14:43

I like to use the Mathematica plugin for Eclipse (or the Workbench) for development. It's very simple to build packages, you can write the documentation for your functions (as well as Guides and Tutorials) and you can deploy your package to your Mathematica installation so both your functions and the documentation are integrated with the built-in ones.

It works very nicely (and the same for webMathematica if you're interested).

There is an extremly nice tutorial "Building Packages: A basic tutorial" by David Reiss (Scientific Arts).

It is in a notebook format and a the link to it can be found at http://community.wolfram.com/groups/-/m/t/214901