One idea is that we don't need to necessarily do this with includes. We could simply add an option (e.g. EnableDropinDirectories) that enables the drop-in directories for a particular hook. It doesn't account for renaming the hook but in my opinion, I don't think that will be a massive issue in practice.
Daan On Sat, 5 Sep 2020 at 02:31, Andrew Gregory <[email protected]> wrote: > > On 09/04/20 at 12:22pm, Allan McRae wrote: > ... > > I'm trying to figure out how includes would address this problem. > > > > We have a hook that runs when its triggers are met. We want to have a > > package add additional triggers, by dropping in a file into our config, > > but do not want to duplicate the function of the hook, or to directly > > edit the hook. An Include would provide a place where we can drop more > > config files with (e.g.) more triggers, but that requires the original > > hook to be set up such that it is extendable. Just adding additional > > triggers does not require the original hook to do anything. > > Requiring the hook to opt-in to this behavior is the point. Once you > make a hook extensible, making any changes to that hook become much > more difficult because those changes could render any extensions > useless, and the hook author doesn't have any way to know if anything > else is depending on the current implementation. Requiring the hook > to opt-in gives the author a way to indicate that the hook is suitable > for extension and won't change in a way that breaks those extensions > in the future. Essentially we're allowing a hook to choose to provide > a public interface instead of automatically doing it for all hooks. > And, of course, the fact that we already have code to deal with > Includes is a nice plus.
