Comment 2 for bug 1877448

> 1) Can you give me a use-case for where you'd want the exact same thing triggered upon multiple events?

Two thoughts there. One would be that you could have a configuration hook that you'd want to run on install for "zero configuration". Basically to init things. The other would be that you have an interface hook that would be on multiple interfaces.
> 2) If you define multiple hooks that are triggered by the same thing, how should snapcraft determine the order in which to execute them? Does it matter?
For the use-cases I was thinking of it wouldn't. But I could imagine that perhaps someone would need that. A solution there could be to include an "after" clause similar to how parts work in snapcraft. That seems to have worked well there. I think you'd want to keep it simple, for complex cases a user could build their own shell script.
On Jun 19 2020, at 12:47 pm, Kyle Fazzari <email address hidden> wrote:
> I very much support hooks mirroring apps. In fact, that's what the
> original proposal was[1]. The "trigger" idea is new though. Two
> questions come to mind:
>
> 1) Can you give me a use-case for where you'd want the exact same thing triggered upon multiple events?
> 2) If you define multiple hooks that are triggered by the same thing, how should snapcraft determine the order in which to execute them? Does it matter?
>
> [1]: https://github.com/snapcore/snapcraft/pull/921
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1877448
>
> Title:
> Hooks stanza doesn't match parts and apps
>
> Status in Snapcraft:
> New
>
> Bug description:
> Working on adding some font hooks for the Inkscape package it was my
> first time using hooks, and I found it kinda confusing. I think this
> largely stemmed from the fact that the hooks section works differently
> than the parts and apps sections.
>
> The hooks section is abstractly like this: hooks.$trigger.$parameter
> Where apps and parts are mostly like this: apps.$name.$parameter
> I think that the $name attribute is useful for organization and allows
> for more flexible hooks. For instance I'd suggest what is now:
>
> hooks:
> configure:
> plugs: [ desktop ]
>
> Would look more like this:
> hooks:
> update-font-cache:
> trigger: [ configure ]
> command: update-font-cache.sh
> plugs: [ desktop ]
>
> This would allow for better organization and documentation of hooks.
> Of course this would require some translation as snapd expects the
> original format. But that could be achieved with Snapcraft building a
> shell script for each trigger calling the appropriate hooks.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1877448/+subscriptions
>