Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Implement hooks for plugins #1578

Closed
fabiopelosin opened this Issue · 6 comments

5 participants

@fabiopelosin

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`
    end

  end
end

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.

@swizzlr

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...

@fabiopelosin

I hope that made sense...

Of course it made... http://i.imgur.com/3f0GA.gif

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.

@swizzlr

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

@orta
Owner

some of this is done, see this example using it: https://github.com/CocoaPods/cocoapods-install-metadata

@CocoaPodsBot
Collaborator

Issue has been confirmed by @neonichu

@kylef
Owner

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.