charmcraft 2.4.0 is stricter about reactive part names

charmcraft
1

A number of Launchpad’s charms are still using the reactive framework for reasons I won’t go into right now. We noticed that they were misbuilding with charmcraft 2.4.0: in the packed charm, config.yaml and other similar top-level files were just copies of those files from the topmost layer, rather than correctly merging information from all layers. This looked very much like charmcraft#1150, except that for us it was a new occurrence of that bug in a release that was supposed to fix it.

On closer inspection, I found that the problem is because we were calling our top-level parts something other than charm. I’d interpreted that part of the documentation as a placeholder, but in fact it seems that it has functional importance. I’ve applied changes to all our charms along the lines of this merge proposal, and I’ve checked that there are no other charmcraft.yaml files on my laptop with the same bug, but one of my team mentioned that it might be worth posting about it more widely in case anyone else runs into the same problem; I agree.

2 Likes
2

Huh, that’s a very interesting one…

Charmcraft has a little bit of “magic” with building charm and bundle parts. I don’t remember the exact details, but essentially it’ll fill in a charm or bundle part for you if you don’t have one (or if you don’t have any parts). My guess is that there was a subtle change in the behaviour that caused this.

My personal hope is to eventually deprecate that magic, relying instead on a combination of a more explicit init and better documentation (and caring as little as possible about part names), but for existing bases that regression is still a problem.

I’ve filed it as a bug since it is a regression: https://github.com/canonical/charmcraft/issues/1360 Though since nobody else seems to have come across it and you have a workaround, the priority may be fairly low.

My apologies too for not responding to this faster.