8.6: Managing Dependencies Between Packages

Last updated
Save as PDF

Page ID: 43839

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

A project is generally composed of several packages, which often have dependencies on other packages. It is also likely that a certain package depends on a specific version of another package. Handling dependencies correctly is really important and is one of the major benefits of Metacello. There are two types of dependencies:

Internal dependencies. There are several packages inside a project; some of them depend on other packages of the same project.

Dependencies between projects. It is common for a project to depend on another project or on some packages from another project. For example, Pier (a meta-described content management system depends on Magritte (a metadata modeling framework) and Seaside (a framework for web application development).

Let us focus on internal dependencies for now: imagine that the packages CoolBrowser-Tests and CoolBrowser-Addons both depend on CoolBrowser-Core as described in Figure \(\PageIndex{1}\). The specifications for versions 0.1 and 0.2 did not capture this dependency. Here is a new configuration that does:

ConfigurationOfCoolBrowser>>version03: spec
    <version: '0.3'>

    spec for: #common do: [
        spec repository: 'http://www.example.com/CoolBrowser'.
        spec
            package: 'CoolBrowser-Core' with: 'CoolBrowser-Core-BobJones.15';
            package: 'CoolBrowser-Tests' with: [
                spec
                    file: 'CoolBrowser-Tests-JohnLewis.8';
                    requires: 'CoolBrowser-Core' ];
            package: 'CoolBrowser-Addons' with: [
                spec
                    file: 'CoolBrowser-Addons-JohnLewis.3';
                    requires: 'CoolBrowser-Core' ]].

Versions diagram with internal dependencies. — Figure \(\PageIndex{1}\): Version 0.3 expresses internal dependencies between packages in the same project.

In version03: we have added dependency information using the requires: directive.

We have also introduced the file: message, which refers to a specific version of the package. Both CoolBrowser-Tests and CoolBrowser-Addons require CoolBrowser-Core, which must be loaded before they are loaded. Notice that we did not specify the exact version of Cool-Browser-Core on which they depend. This can cause problems — but don’t worry, we will address this deficiency soon!.

With this version we are mixing structural information (required packages and repository) with version information (the exact number version). We can expect that, over time, the version information will change frequently while the structural information will remain more or less the same. To capture this, Metacello introduces the concept of Baselines.