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 – and tend to get more complex as time goes by. For the past six odd years, the Snapcraft team has worked on making their core product modular, efficient and useful to snap developers, extending its functionality and introducing new capabilities over time. In a way, it is a complete product, and it serves its purpose well. But there are ways to make things even better. This article looks at the future of Snapcraft.

Life in the fast lane

The basic concept revolves around breaking Snapcraft apart – into smaller, even more modular and reusable components that can be utilized across a range of different products. The common foundation for this effort is a set of Craft Libraries, as we have already discussed in the Craft Parts blog post. The theory calls for the use of a generic parts builder based on craft-providers and craft-parts, with added Snapcraft functionality as a separate layer. The only question is, what is the airspeed velocity of a swallow how difficult would this be to architect and implement?

Just before the holidays season, the Snapcraft team set about answering that exact question, and to examine the extent of modularity in their approach.

Here’s a quick digest of the work done:

• The current Snapcraft codebase is now considered legacy. The main entry point of this package is executed when fallback to legacy Snapcraft is required. 
• Legacy Snapcraft keeps project configuration data in dictionary form. This was changed to use a pydantic model. Likewise, the JSON schema will need to be maintained separately.
• A simple prototype was made using the core22 base (development image), resulting in an installable snap package containing a test application.

More work to be done

The early proof of concept only covers some aspects of the Snapcraft functionality, but it did illustrate a relatively quick conversion to the new modular design. However, there are still quite a few technical challenges that need to be addressed, including data validation on a global level, grammar processing, extensions, part information adoption, Appstream info adoption, Snapcraft-specific plugins re-implementation as application plugins for craft-parts, or binary file patching.

Then, there are also the command-line argument processing implementation using craft-cli, new Store interactions and remote build functionality, as well as making the command-line user experience cleaner and more consistent.

What about legacy code?

It is important to note that this (somewhat) radical change will not disrupt the current usage model. Projects with core18 and core20 will continue using monolithic Snapcraft, whereas the new, modular Snapcraft will be used for core22 and later. A fallback mechanism will be placed to decide which implementation is required in the build process. This way, the thousands of projects happily using Snapcraft can continue working, and will only be affected if and when they move to the new base.

Summary

To boldly go where no one has gone before. This is true for spacecraft as well as Snapcraft. Going forward, you should expect to see quite a few new, interesting developments in the product, all aimed at making things simpler, faster, more robust, and without adversely affecting the user experience. If you have any comments or ideas, or perhaps if you’d like to contribute, please join our forum and let us know your thoughts.