Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Implement hooks for plugins #1578

fabiopelosin opened this Issue · 6 comments

5 participants


This feature is about implementing hook system for CocoaPods plugins.

The plugins are loaded by claude early on in the execution of a new command (precisely in the run call). At this point the CocoaPods code has already been loaded so plugins have the chance to override it. However this approach is brittle and makes complex to call the original implementation (aliasing and overriding a method would work). Hence a more robust plugin system is needed.

One important consideration about a hook system for plugins is that hooks tend to be sticky as plugins will depend on them and thus pose a burden that affects negatively the evolution of the CocoaPods codebase. For this reason is crucial that hooks should be as simple as possible and pass only primitive data types (otherwise chaining the classes is problematic).

A proposal for the hooks implementation from the point of view of the plugin is:

module Pod
  Class PlugIn

    PluginsManager.on_post_install do |argument|
       `rm -rf Pods | ;-P`


The argument given to the hook should be just one, a hash or a struct or another form of data storage class which can store information in the terms of primitive data types. For example for the above hook it could be:

  :installation_dir => '~/path'

Another important consideration is that the hooks manager should support the registration of multiple blocks for a given hook as multiple plugins might use that same hook.

It is crucial that we add hooks only when a reasonable need for the arises. The same goes for the data passed in the argument.


It strikes me that if a kind of primitive purity is enforced in order to not encumber the codebase with legacy support, this ought to be the case in podfiles as well. If that were possible, then they could be loaded into the same kind of system: the gem has a global stack of blocks to execute at each hook, some from the plugins, some internally (a nice refactoring/atomization, perhaps isolating side-effects more clearly?), and finally from the podfile itself.

I hope that made sense...


I hope that made sense...

Of course it made...

If I understood your correctly we tried to do that with the Podfile hooks, however as a similar system was not originally in place we had to find some sort of compromise to keep backwards compatibility.

About using this system for architecture of the whole gem I never considered this alternative, I think nobody else ever did. Interesting nonetheless, however I'm afraid it won't work because we have too much state to pass around. This state would define in turn an implicit contract with those hooks limiting the evolution of the architecture.


Well, that aside, I guess a singleton plugins manager is a good starting point. I'll write some tests soon (busy week).


some of this is done, see this example using it:


Issue has been confirmed by @neonichu


This was shipped in 0.34.0.rc1

@kylef kylef closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.