‌

Packages

We talked briefly before about packages in the context of programming, but we haven't talked about packages as an organizational structure in Mathematica.

As with most languages, packages provide a way to bundle together different code files and resources. By creating a package a developer allows disparate functionality to act as a single unit. There are packages in C, Java, Python, etc. and while they all have subtle differences in setup and exact usage, they all serve the same purpose. In this regard, Mathematica is no different.

We'll go more into how to set up one's own packages in a later post, but first we'll deal with some terminology.

Package File

Mathematica packages come in two variants. The first is simply bundling a number of functions into a single file with the extension ".m" or ".wl"

We talked about this earlier so in order to minimize repeating myself I won't go into this here.

The main case where this type of package is useful is when the size of the code is not particularly large, there aren't any external resources that should be distributed with the package, versioning and updating is not a concern, and no metadata needs to be stored.

Surprisingly this covers the major use case most casual coders will handle.

A package file can simply be installed via Get , so often one need not install a package file explicitly to make use of it.

Paclet

Since the term "package" was already used, what most programming languages call a package Mathematica calls a "paclet".

A paclet is simply a .zip archive by another name that bundles code, resources, and metadata in a way that Mathematica's native package manager (the PacletManager system) can deal with. Paclets provide an easy way to install code, resources, stylesheets, palettes, and documentation via the PacletInstall function.

When we discuss packages for the rest of this section we will generally be talking about paclets, not package files themselves.