Forum: Ruby Plugin type discovery/registration - How do I discover what

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jeff B. (Guest)
on 2006-02-27 19:53
(Received via mailing list)
In my current project I am in need of a standard plugin mechanism where
I
discover what plugins are available by what exists in a directory. I was
able to easily simply 'require' these ruby files in. However I want to
take
it a step further and know (discover) what classes were in these files
including the module name so that I can interrogate them further and
potentially create them and call an initialize type method which might
be
used to register yourself and or do other startup processing.

Is there an easy way to know what classes were loaded during the require
or
is there a better way to do this sort of thing? I think the Rails plugin
mechanism works similarly to what I am looking for in that it loads
plugins
from a directory and invokes an initialize method on each so they can do
their own registration/configuration work.

PS. It would also be nice if the plugins can use whatever module space
they
want so there won't be class conflicts, so I would prefer suggestions
and
ideas that might allow this functionality, so not only do I get the
class
name but the actual module::class name so that I could create the proper
object using this information.

Thanks for any suggestions or help!

Jeff
James G. (Guest)
on 2006-02-27 20:05
(Received via mailing list)
On Feb 27, 2006, at 11:52 AM, Jeff B. wrote:

> Is there an easy way to know what classes were loaded during the
> require or
> is there a better way to do this sort of thing?

See if this recent post helps:

http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/181245

Also see Ara's dynaload library:

http://rubyforge.org/frs/?group_id=1024&release_id=3786

Hope that helps.

James Edward G. II
Gene T. (Guest)
on 2006-02-27 20:21
(Received via mailing list)
James Edward G. II wrote:
> Also see Ara's dynaload library:
>
> http://rubyforge.org/frs/?group_id=1024&release_id=3786
>

this is relevant too, I think
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...
Joel VanderWerf (Guest)
on 2006-02-27 21:07
(Received via mailing list)
Jeff B. wrote:
> mechanism works similarly to what I am looking for in that it loads plugins
> from a directory and invokes an initialize method on each so they can do
> their own registration/configuration work.
>
> PS. It would also be nice if the plugins can use whatever module space they
> want so there won't be class conflicts, so I would prefer suggestions and
> ideas that might allow this functionality, so not only do I get the class
> name but the actual module::class name so that I could create the proper
> object using this information.
>
> Thanks for any suggestions or help!

Kernel#module_eval is a good tool for wrapping up plug-ins inside a new
namespace. I wrote the "script" library on raa to simplify doing that.
For example:

$ cat plugins/plug1.rb
class Plug1
end

K = 42

$ cat plugins/plug2.rb
class Plug2
end

K = 43

$ cat plugin.rb
require 'script'

plugins = Dir.glob("plugins/*.rb").map do |file|
  Script.load file
end

p plugins

plugins.each do |plugin|
  puts "plugin #{plugin} defines these constants:"
  plugin.constants.each do |const_name|
    val = plugin.const_get(const_name)
    puts "  %20s = %s" % [const_name, val.inspect]
  end
  puts
end

$ ruby plugin.rb
[#<Script:/path/to/plug1.rb>, #<Script:/path/to/plug2.rb>]
plugin #<Script:/path/to/plug1.rb> defines these constants:
                 Plug1 = #<Script:0xb7d61414>::Plug1
                     K = 42

plugin #<Script:/path/to/plug2.rb> defines these constants:
                 Plug2 = #<Script:0xb7d613c4>::Plug2
                     K = 43


(I substituted /path/to/ for the full path to save space.)

Of course, you can filter out only the classes, and skip other
constants.
Jeff B. (Guest)
on 2006-02-27 23:20
(Received via mailing list)
Thanks for the quick responses and wonderful suggestions, these are
great! I
can see where each of these techniques would be useful in slightly
different
ways.
This topic is locked and can not be replied to.