No support for reactive charms with multiple bases

[fnordahl]

Ubuntu Focal ships with Python 3.8, Ubuntu Jammy ships with Python 3.10. For any charm with anything other than the most basic wheelhouse dependencies, building the charm for Python 3.8 and expect it to run on a Python 3.10 system does not really work well.

Charmcraft and charmhub give us the tools to fix this, but the current build model prevents the use of the long awaited functionality.

At present the build target for reactive charms relies on a rename.sh script which renames all *.charm files in the top level charm directory to something the functional test gate can recognize for deployment.

This does not work well for charms that specify multiple bases, for example:

bases:
  - build-on:
      - name: ubuntu
        channel: "20.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "20.04"
        architectures: [amd64, s390x, ppc64el, arm64]
  - build-on:
      - name: ubuntu
        channel: "22.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "22.04"
        architectures: [amd64, s390x, ppc64el, arm64]

With the above configuration charmcraft will produce the following files:

my-charm_ubuntu-20.04-amd64-s390x-ppc64el-arm64.charm
my-charm_ubuntu-22.04-amd64-s390x-ppc64el-arm64.charm

We ought to remove the rename.sh script and add support in the CI to make use of the correct charm for the correct target.

[lathiat]

build-on(amd64) but run-on(s390x, ppc64el,arm64) I believe is also not be valid for much the same reason.

It works for arch-independent wheels but any wheel with a binary component will fail. Given the dependency graph of bases and their dependencies it may not be possible to reason about whether any given charm includes binary components?

From my current understanding I am told that Launchpad can remote-build charms (similar to snaps) but only using Launchpad recipes and there is not currently an equivalent to "snap remote-build" or the ability to cross compile (though there is some prior art for cross compiling wheels at https://github.com/benfogle/crossenv)

In any case the same fix here will make it so that multiple architectures can be built but the machinary to aquire and build it on those architectures and get the files all together for upload may be additional work. Unclear to me if that needs to be filed as a separate bug somewhere or if any charms are currently affected by this.

[fnordahl]

For Classic charms, only Python source code is shipped and any Python dependencies come from installed debs. For Reactive charms the charm tools ensure that only source wheels are distributed and any dependencies requiring building will be built at install time. Both of these mechanisms have their problems and drawbacks.

For Operator Framework machine charms we hopefully can get rid of that madness and rely on launchpad built binaries, but we do indeed need some CI fixes to cope with that too.