Distinguishing projects from packages

Internals & Design
, ,
41

Update – terminology I ended up using in the Pkg3 documentation:

https://julialang.org/Pkg3.jl/latest/index.html#Glossary-1

Quoting the relevant parts:

Project: a source tree with a standard layout, including a src directory for the main body of Julia code, a test directory for testing the project, docs for documentation files, and optionally a build directory for a build script and its outputs. A project will typically also have a project file and may optionally have a manifest file:

Package: a project which provides reusable functionality that can be used by other Julia projects via import X or using X. A package should have a project file with a uuid entry giving its package UUID. This UUID is used to identify the package in projects that depend on it.

Application: a project which provides standalone functionality not intended to be reused by other Julia projects. For example a web application or a command-line utility. An application may have a UUID but does not need one. An application may also provide global configuration options for packages it depends on. Packages, on the other hand, may not provide global configuration since that could conflict with the configuration of the main application.

Projects vs. Packages vs. Applications:

  1. Project is an umbrella term: packages and applications are kinds of projects.
  2. Packages should have UUIDs, applications can have a UUIDs but don’t need them.
  3. Applications can provide global configuration, whereas packages cannot.

I’ve found this terminology to be intuitive and helpful. Having “project” as an umbrella term for both packages and applications is good since otherwise you find yourself using the overly long and awkward phrase “packages or applications” over and over in situations where the term “project” is quite natural and easy.

10 Likes