Craft Parts – Reusable code, Snapcraft style

by Igor Ljubuncic on 26 November 2021

Throughout the ages, humans have always used simpler tools and materials to create more complex ones. Wood and stone for smelting bronze and iron; iron to create steel; vacuum tubes to create logical gates; logical gates to create advanced arithmetic engines, and so on. Modern software is no different.

With Snapcraft in particular, the snap building process comprises a number of steps. Source artifacts are collected, there’s compilation and assembly of binary products, and then, these are packaged into a single final archive. This process is very similar to how various other Canonical solutions work, and applicable to many different use cases outside of the snap world. To that end, the Snapcraft team has created a portable, reusable mechanism called Craft Parts.

A cycle of life

Craft Parts can obtain data from different sources, process it in various ways, and prepare a filesystem subtree suitable for deployment. Similar to how it’s done with snaps, the components used in the project specification are called parts, and they can be independently downloaded, built and installed.

The heart of the craft_parts module is the Lifecycle Manager component, which coordinates and executes all the steps in the parts lifecycle. At first, the idea may look a bit abstract, but for those who have built snaps before, the general approach will look quite familiar. As an example:

import yaml
from craft_parts import LifecycleManager, Step

parts_yaml = """
    plugin: autotools
      - usr/local/bin/hello
      - usr/local/share/man/*

parts = yaml.safe_load(parts_yaml)
lcm = LifecycleManager(parts, application_name="example", cache_dir=".")
actions = lcm.plan(Step.PRIME)
with lcm.action_executor() as aex:

In the example above, the Lifecycle Manager will download the hello tarball, unpack it, run its configuration script, compile the source code, install the resulting artifacts, and extract only the files we want to deploy (as specified by the prime keyword).

The final result will be a subtree containing the following files:


There are several practical software building advantages to this approach:

  • The user does not need to manually compile the artifacts – in this example, the autotools plugin, contained in the module, will handle the default compilation. If required, users who require more flexibility can introduce overrides.
  • The compilation is done relative to the project directory, allowing portability of the final code. Again, the command-line tool offers additional flexibility, which can help create applications for different use cases and scenarios, without relying on any strict host system layout.

Overall, you can use the Lifecycle Manager to create subtrees of binary code and libraries, test whether you can shorten and simplify your compilation effort in comparison to traditional methods and tooling, and if you can make your applications easier to deploy.


At the moment, Craft Parts is designed to run on Ubuntu and requires Python 3.7 or higher. The mechanism is still in (very) early stages, so this is a great opportunity for software enthusiasts and tinkerers to step in and try the tool. Your feedback and ideas could help make Craft Parts even more extensible and useful. So please, test the framework, join the Snapcraft forum, and let us know what you think.

Photo by Nicolas Hoizey on Unsplash.

Newsletter Signup

Related posts

The Future of Snapcraft

System hysteresis, when applied to software, can roughly be defined as an overall lag between desired implementation of code and actual implementation of said code. Ideally, this delay should be minimal, and programmers would be able to make instantaneous changes and improvements to their applications. In reality, things are more complex […]

The long ARM of KDE

With over 100 applications available in the Snap Store, KDE is by far the biggest publisher of snaps around. What unifies this impressive portfolio is the fact that all of these snaps are made for the x86 platform. Not anymore. Now, don’t panic! The x86 snaps are not going anywhere. But ARM-supported KDE snaps are […]

The new classic confinement in snaps – Even the classics need a change

As part of their fundamental, security-driven design, snaps are meant to run isolated from the underlying system. In most cases, the idea works well, and granular access to system resources using the mechanism of interfaces allows snap developers to ship their applications packaged with strict confinement. However, there are some scenario […]