juju
Don't embed hooks
Currently, layered charms' hooks are an embedded chunk of Python. This might come from the base layer, or an old version of the base layer, or customized by an included layer, or customized by the main charm. This makes it difficult to propagate fixes, and is a bit of a mess.
Instead, lets not have any hooks in the hooks directory. List the hooks that each layer needs in its layers.yaml file. At composition time, copy hooks/hook.template into place for each hook and set executable permissions, if the hook does not already exist.
This would allow changes in the base layer's hook.template to propagate. It would allow layers and charms to create a new hook.template if necessary. It would allow layers and charms to override the hook template just for those hooks that actually need it.
For extra points, by stealing some code from charms.reactive it would be possible to list hooks like {interface:pgsql}-relation-changed and have hooks generated with the correct relation name based on the final composed metadata.yaml.
This would also allow layers to be used by alien charms, such as a Windows charm using the leadership layer.
I don't know if this is at all related, but with charm-tools 2.1.2, it seems like I have to have a hooks/hook.template file even if it's empty. Without this, charm build complains:
build: At least one layer must provide hooks/hook.template
touching hooks/hook.template quiets the warning, but I don't really understand what the file is for.
Okay, I think I see that hook.template gets copied to data-storage-attached and data-storage-detaching, but then I'm unclear why it won't do the same with the other hooks.
This bug still causes an error level information to me:
build: At least one layer must provide hooks/hook.template
Its coloured "red" in the charm build output which leads up to a situation where I don't know if its a problem I need to fix or can opt-out to fix.
If there is a better way to remove this error/warning
@erik78se Do you still get the problem if you build with --no-local-layers? You might have an old version of the base layer pinned, in which case what you see is a valid error report.
@stub42 I've tore down my development environment - sorry, I can't reproduce this easily.
I ran into this with the haproxy charm on r128: https://bazaar.launchpad.net/~haproxy-team/charm-haproxy/trunk/revision/128
bzr branch lp:charm-haproxy haproxy
Branched 128 revisions.
cd haproxy
charm build --no-local-layers
build: Build dir not specified via command-line or environment; defaulting to /tmp/charm-builds
build: Please add a `repo` key to your layer.yaml, e.g. repo: bzr+ssh://bazaar.launchpad.net/+branch/charm-haproxy/\n'
build: Destination charm directory: /tmp/charm-builds/haproxy
build: The top level layer expects a valid layer.yaml file
build: Processing layer: haproxy (from .)
build: At least one layer must provide hooks/hook.template
Touching the hooks/hook.template file does indeed allow building the charm:
touch hooks/hook.template
charm build --no-local-layers
build: Build dir not specified via command-line or environment; defaulting to /tmp/charm-builds
build: Please add a `repo` key to your layer.yaml, e.g. repo: bzr+ssh://bazaar.launchpad.net/+branch/charm-haproxy/\n'
build: Destination charm directory: /tmp/charm-builds/haproxy
build: The top level layer expects a valid layer.yaml file
build: Processing layer: haproxy (from .)
proof: OK!
I think I'm running the correct charm snap:
jamon@derp:pts/2: /home/jamon/charms/haproxy
0 % charm version
charmstore-client 2.3.0+snap-320+git-47-g44bc628
charm-tools 2.5.2
The cited haproxy charm is not a reactive charm and has no layer.yaml, and 'charm build' is failing as expected.
Perhaps 'charm build' should fail more obviously if there is no layer.yaml, given that in almost all cases a built charm will fail without one of the base layers included. A missing layer.yaml is either a fatal mistake, or indicates the charm does not need building (not a charms.reactive charm)
Makes total sense now, I didn't realize I was working with a non-reactive charm there. Thanks for explaining that.
We should report building non-layered charms better and earlier in the process. Created #512 to track that.
Yes, thats a very good idea. Considering it took me a long time to understand the difference and how it mattered.
I wrote a long "hook" tutorial which tried to emphasize this which I think was a major misstake from my side, not learning that from start before hitting the "reactive" wall.
/Erik
On Mon, Mar 25, 2019 at 4:19 PM Cory Johns [email protected] wrote:
We should report building non-layered charms better and earlier in the process. Created #512 https://github.com/juju/charm-tools/issues/512 to track that.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/juju/charm-tools/issues/98#issuecomment-476244059, or mute the thread https://github.com/notifications/unsubscribe-auth/AAz6qyAVzgaqYcBMNdtZF9KnNg4FtPiOks5vaOjngaJpZM4HRL5M .