Add `output-file` to charmcraft.yaml so the developer can control the resulting file name

[wallyworld]

I have a charm which needs to be built on say focal but run "everywhere". It's a simple charm with just a bit of Python - nothing series or arch specific. So I have a charmcraft.yaml file like below. I need to explicitly list all series and arches, and the 4 arches I have included are now no longer the complete set - more have been added, eg riscv etc. When I pack the charm, I get a file name like this:

juju-controller_ubuntu-20.04-amd64-aarch64-arm64-s390x_ubuntu-18.04-amd64-aarch64-arm64-s390x_ubuntu-16.04-amd64-aarch64-arm64-s390x.charm

And there's no tab completion so charmcraft upload is fun to use :-)

Things will only get worse when more arches and/or series are added.

What I'd really like is a way to say the charm runs "everywhere". Or at least channel=all arch=all or something. And a nicer filename, or at least tab completion. Imagine what things will be like when more series and arches are added.

For reference, here's a related charmhub issue

https://github.com/canonical-web-and-design/charmhub.io/issues/1104

type: charm
bases:
    - build-on:
        - name: ubuntu
          channel: "20.04"
          architectures: ["amd64"]
      run-on:
        - name: ubuntu
          channel: "20.04"
          architectures: 
              - amd64
              - aarch64
              - arm64
              - s390x
        - name: ubuntu
          channel: "18.04"
          architectures: 
              - amd64
              - aarch64
              - arm64
              - s390x
        - name: ubuntu
          channel: "16.04"
          architectures: 
              - amd64
              - aarch64
              - arm64
              - s390x

[sergiusens]

We can consider the introduction of the "all" keyword (pending agreement work with juju and charmhub). But you can also build your PyYAML package with libyaml which would make it much faster but architecture dependent.

But consider that use of all would mean that you as a charm publisher are signing up to supporting platforms not on your list. Is your test matrix covering all the mentioned architectures in each base definition?

[wallyworld]

In this case, the charm is automatically deployed on the Juju controller machine, so it needs to run on whatever arch we support Juju on. It's a non platform specific bit of Python. It will be tested each time Juju bootstrap is tested on the supported arches.

[facundobatista]

Maybe we could give control on the file name to the developer. I mean, introduce a new key in the config for it inside the bases config, so the developer can choose how the final result will look like. This way we can avoid having all which is a kind of a "corner case", and have the flexibility of developers building for "a lot but not all", expressing that in the file name as they want.

[wallyworld]

Having a way to specify the file name would be nice.

[sergiusens]

We will add a charmcraft.yaml option call output-file with is a string which we will format with the base_index, so something like this in code config["output_file"].format(base_index=index)

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CRAFT-3413.

This message was autogenerated

[lengau]

While it's still not this full feature, Charmcraft 3 does let you better control the charm's filename(s) by providing a name for the platform. For example, a charm like:

name: my-charm
base: ubuntu@24.04
platforms:
  my-platform:
    build-on: [amd64]
    build-for: [amd64]

will result in a charm called my-charm_my-platform.charm