On Wed, Aug 20, 2014 at 11:46 AM, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
> People must be aware that there > is a multitude of events dispatched to that one executable, > potentially with events they do not expect, and they must be aware > that by creating a different hook they will prevent that one > executable from receiving that event. That's what "missing-hook" > conveys to me. If you think that's too subtle, maybe we need a > different proposal. Maybe we *do* need a different proposal. The bug <https://bugs.launchpad.net/juju/+bug/1009687> that is linked in the pain points spreadsheet mainly lists it as a way to avoid having 20 symlinks to the same script. Using it merely for a few "missing" hooks did not seem to be the main focus, even if it is the effect of the suggested implementation (which is what I implemented). The code, as-is, adds a lot of logical complexity that is unnecessary. Here's a proposal that is much simpler: we add a flag to the charm metadata, called something like "single_hook". When single_hook is true, *all* hook events run a file called "default-hook" (or whatever we want to call it, I don't really care). $JUJU_HOOK_NAME will be set with the name of the hook that is running. That's it. What the charm authors do after the hook file gets run is up to them. In the bug's comments, there's discussion about a lack of discoverability for what hooks the charm has... but honestly, if you need to know what the hooks do, you have to read the code anyway. Hopefully knowing what hooks a charm has shouldn't be necessary to *use* the charm (if using Juju requires you to read a charm's code... we're doing something wrong).
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
