Upcoming charmcraft changes and a call for testers

charmcraft
1

Charmcraft has some exciting changes in the works, and we’d love some help testing them on the edge channel!

Strict dependency management

The first feature we’re adding is strict dependency management. Previously, there were four different sources of dependencies for a charm (requirements files, charmlibs dependencies, the charm-python-packages keyword, and the charm-binary-python-packages keyword). If you opt into strict dependencies, that goes down to one: your requirements files.

Here’s an example charmcraft.yaml file using strict dependencies:

type: charm
name: strict-deps
summary: Strict dependencies sample charm
description: |
  A sample charm with strict dependencies enabled.
bases:
  - name: ubuntu
    channel: "22.04"

parts:
  charm:
    charm-strict-dependencies: true
    charm-binary-python-packages: ["ops"]

Keen observers may have noticed that charm-binary-python-packages is still available here. The semantics are, however, slightly different when strict dependencies are enabled. Rather than providing a list of pip install parameters, this parameter becomes simply a set of package names which are allowed to be installed from prebuilt wheels rather than from source.

Likewise, any charm libraries on which your charm depends will have PYDEPS as before, but each of those dependencies must be listed in your requirements files too.

The short version:

Enable charm-strict-dependencies for your charm part and charmcraft will only use your requirements files to install dependencies, failing with an error if other dependencies are needed.

Shared host-level pip caching

Next, people have been eagerly requesting a way to cache built artefacts from pip, and this is now doable! By default, charmcraft will share your pip built wheel cache between build providers on the same machine (meaning if you’re building multiple charms, you can skip the same time-consuming rust builds during the build process). Furthermore, setting the CRAFT_SHARED_CACHE environment variable allows you to set a base cache directory, allowing you to control where these are stored for your CI.

I would advise against using cached artefacts when building for release, but this can definitely help you speed up your CI when running PRs.

Extensions

Thanks to some great work by @syu-w, charmcraft now has a basic form of extensions, similar to Rockcraft and Snapcraft. We’d love for people to try these out and send feedback!

Thanks in advance!

Thank s to anyone who checks these out! Please feel free to file bug reports on GitHub as you come across any issues or ask clarifying questions here.

2 Likes
2

Are there any docs or examples available using CRAFT_SHARED_CACHE, or a deeper explanation on charm-strict-dependencies? A quick search in the charmcraft docs didn’t find anything.

1 Like
3

Thanks for pointing out the lack of docs - I’ve added issues for both.

For examples of the use of CRAFT_SHARED_CACHE - point it to an empty directory that you can write to and charmcraft will use that for caching the same way it by default uses ~/snap/charmcraft/common/cache

4

@lengau Is there any guidance about when it is preferred to use charm-strict-dependencies vs. the old way?

I know the docs haven’t been written yet, but when they are, it would be nice to cover the workflow from the point of view of the developer. I say that because I tried enabling it, and I got lost in a maze of indirect dependencies. I know I could use pip freeze to get the list of all dependencies, but it would be nice to have some guidance on how a charm developer should handle upgrades when strict dependencies are in use.