Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PLUSHOOK_PATH and super-plugins #45

Open
stuartpb opened this issue Sep 14, 2014 · 2 comments
Open

PLUSHOOK_PATH and super-plugins #45

stuartpb opened this issue Sep 14, 2014 · 2 comments

Comments

@stuartpb
Copy link
Member

I was thinking earlier about how I would do a hook-agnostic super-plugin that simply provides an alternate PLUSHU_DIR with an alternate .plushurc to all of its sub-plugins.

Something akin to $PATH, to add successive search paths for plugins, could work, except it wouldn't provide a mechanism to source .plushurc before calling the super-plugin's sub-plugins' hooks.

Other thoughts:

  • plushook gets source points, like plushu.
@stuartpb
Copy link
Member Author

Food for thought: the original concept of super-plugins was formed with the primary aim of sandboxing commands (circa March/May 2014 as a Dokku patch), which have the commands source .sh scripts.

@stuartpb
Copy link
Member Author

I was thinking about why this can't just plushook for the original PLUSHU_DIR and then plushook for the secondary PLUSHU_DIR, and:

  • Those plugins would not be mixed in to the plugin order for each other
  • The first plushook call consumes stdin,so the second one can't use it
  • That solution can't apply for all hooks, which a plugin like the aforementioned would reasonably want. (It's a reasonable plugin because setting variables in .plushurc is considered one of the more sane bases of plugin configuration, where not just doing that would be overcomplicating things.)

So, what I'm thinking now: maybe the core components of plushook (the file-oriented numeric sort and the input-multiplexing-if-needed execution) should be split off into their own scripts.

I was thinking a plugin would then use these to perform plushooks when it wanted to hook into these alternative plugin directories alongside the original plugins (avoiding the first two issues), but this still doesn't allow a plugin to expose its own plugins to any plushook call.

I'm loath to put any core components of plushook into a wildcarded search path (beyond the actual hook lookup itself), but this might call for a "hook-path" script in plugins, along with a source to run before any hook script under that path (or paths?) is called.

I really worry that's putting too many open holes in the core plumbing component of Plushu, though. I'd rather take a little more time to think of another way as this isn't really a pressing need for me right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant