Plugin system about filewatcher

[AlexWayfer]

I'll try and figure it out later, but I would like to implement it with the help of inheritance, and not before_ and after_ methods. I have successful experience with it in Flame framework with before and after hooks (with super calls).

[thomasfl]

A plugin system is a good idea. It keeps the core small and manageable while still allowing new features to be added.

I haven't thought too much about what an API for a plugin system should look like. The first idea that comes to mind is having a :plugins option in the Filewatcher constructor.

require 'filewatcher/plugins/file_read_detection'

frd = new Filewatcher::FileReadDetection()

Filewatcher.new('**/*.*', plugins: [frd]).watch do |filename, event|
    if(event == :access) do
       puts "Read file detected:" + filename
    end
end

[AlexWayfer]

@thomasfl I thought that all plugins can be loaded (required) by default, and add some options for Filewatcher (include executable), but options is good idea too, also for executable (--plugins), I guess.

[thomasfl]

Having an --plugins options for the cli is a good idea.

When using the filewatcher API with plugins that add features, then the plugins should probably be explicitly imported. That way users could easily create their own plugins.

[AlexWayfer]

So, --help option should show additional info from plugins, listed in --plugins option — OK.

[thomasfl]

I guess a file read detection plugin should be available like this:

  $ filewatcher --plugins fileread **/* 

And visible in the help section like this

  $ filewatcher --help
   --plugins, -p:  Specify plugins to load.
                          "fileread" plugin detects file reads and emits a "fileread" event.

It looks a bit stupid to have a plugin system, when there's only one plugin. Do you have any ideas for other plugins? We could make the spinner available on the command line into a plugin, so there's at least two plugins.

[AlexWayfer]

And visible in the help section like this

I mean something like this:

$ filewatcher --plugins fileread --help
        *standard help*
    Plugins: /* or "Fileread plugin:" */
        --access, -a: Add `access` event (when some file was read)

We could make the spinner available on the command line into a plugin, so there's at least two plugins.

Not bad idea.

It looks a bit stupid to have a plugin system, when there's only one plugin. Do you have any ideas for other plugins?

I think we need to make the system so that third-party developers can add their functionality without changing the main gem. The main thing is the possibility, and the quantity of plugins is already secondary.

[thomasfl]

A plugin could be very simple if it looked something like this:

class FilewatcherFileReadPlugin

   def file_updated?(absolutefilename)
      <if file is read return> do
         return {status: true, event: :fileread}
      end
   end

   def initialize(filenames, options = {})
       ...       
    end

    def before_each_cycle
         print "spinner"
    end

    def after_each_cycle
        ....
    end

end

With this API there should be possible to make plugins that can provide alternative spinners, file read detection and also alter which files should be included in the watch list.

[AlexWayfer]

I think, CLI also can be a plugin. For such cases when user want only Ruby DSL.

Also I'm thinking about a plugin for multiple patterns-commands from YAML file.

[AlexWayfer]

I'm on the way to do it, but I see problems with CLI flags for CLI as a plugin itself. I guess the situation can be better after #144 merge, but it's blocked right now, yes.

[AlexWayfer]

Done! 🎉 In #147.

Now I'm going to:

• make some notes about upcoming major release (2.0) in README;
• release 2.0.0.beta1 or something like this;
• test new plugins with beta-version, fix their CI;
• release Filewatcher 2.0.0 stable;
• test plugins with stable Filewatcher;
• release these plugins.