Fwd: We'd really like to use appable_plugins...

3 views
Skip to first unread message

Brian Takita

unread,
Feb 16, 2007, 5:35:27 PM2/16/07
to pluginaw...@googlegroups.com, Ian McFarland, Nathan Sobo, Parker Thompson
---------- Forwarded message ----------
From: Nathan Sobo < natha...@pivotalsf.com>
Date: Feb 16, 2007 11:25 AM
Subject: We'd really like to use appable_plugins...
To: Parker Thompson <par...@pivotalsf.com >, pluginaw...@googlegroups.com , Ian McFarland <i...@pivotalsf.com>

Hey. Good work on plugins and code reuse across projects. I work for a Rails development shop in San Francisco called Pivotal Labs, and I'd like to thank you for sharing your thoughts on all of this. We've learned a lot from your approach and are excited about appable plugins and their companions.

We're having some issues with appable plugins that we'd like to make you aware of. We're considering moving forward with the spirit of your plugin approach but with our own code, but we'd really like to work together on this for our mutual benefit. We're attaching a toy project that exhibits issues 0 through 2.

0. We can't run your tests

We try to execute appable_plugins_test and fail with the following exception:

/usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_dependencies.rb:33:in `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
        from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_dependencies.rb:18:in `require'
        from ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:309:in `require'
        from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:342:in `new_constants_in'
        from ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:308:in `require'
        from vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plugins/plugin_with_dependencies/init.rb:1:in `load_plugin_without_appable_plugins'
        from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:401:in `load_plugin_without_appable_plugins'
        from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/core_ext/kernel/reporting.rb:11:in `silence_warnings'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in `load_plugin_without_appable_plugins'
        from ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:39:in `load_plugin_without_loaded_plugins'
        from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.rb:57:in `load_plugin'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in `load_plugins'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in `load_plugins'
        from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in `process'
        from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:43:in `run'
        from ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment.rb:8
        from ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
        from vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

We think this is because the embedded rails root requires plugin_dependencies (which we have installed as a gem), but this does not invoke the init.rb associated with this plugin, which does the actual work of mixing in your code with Initializer. How do you guys get this to run?

1. Issues model evaluation order

As we understand it, model classes introduced by appable plugins should be evaluated in the order the plugins were loaded. In our sample app, we two plugins with a "user.rb " model in their app/models directory and a "user.rb" model in our application's model directory.

The "dumb_user" plugin comes alphabetically first, so its init.rb is first to be evaluated. At the top of this init.rb is "require_plugin smart_user". This does indeed cause "smart_user" to be loaded before proceeding with loading

According to our understanding of how appable plugins are supposed to work, upon a lazy load of user.rb, the file from "smart_user" should be evaluated, the file from "dumb_user" should then be evaluated, and then the file from our application.

The order we see instead is "dumb_user", "smart_user", and then the application.

2. When user.rb is not in the application, the last plugin in the chain (which is in the wrong order) is not loaded.

When user.rb is not in the application's models directory, instead of the broken but still workable loading behavior described above, we get something else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated at all.

We know why this happens: Here's the code. Our comment is in all caps above the source of the bug. Can you tell us the intention of this if statement?

def load_from_appable_paths(file_path, method)
  use_strict_file_names = use_strict_file_names?(method)
  use_file_path_for_last_load = use_file_path_for_last_load?(method)
 
  full_file_path = (use_strict_file_names || file_path.ends_with?('.rb')) ? file_path : "#{file_path}.rb"
  file_name = File.basename(full_file_path)
 
  processed = false
  if load_paths = get_appable_paths_for(full_file_path)
    load_paths.each_with_index do |load_path, index|
      # Check if we're using the original file_name on load
      
      ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE THE ELSE BRANCH, THE BUG DOES NOT OCCUR
      if use_file_path_for_last_load && index == load_paths.size - 1
        load_path = file_path
      else
        load_path = "#{load_path}/#{file_name}"
      end
      
      new_result = send("#{method}_without_appable_plugins", load_path)
      processed = true
    end
  end
 
  processed
end

3. Not covered in our toy project investigation are some strange class reloading issues we're experiencing in production apps we're developing. It seems like controllers introduced by plugins are available on the first request but not on subsequent requests in development mode. But this is with version 0.0.1 of appable plugins on Rails 1.2.2, so our information is less solid on this problem.

4. Process issues.

We really like your ideas regarding code reuse across projects, and we're going to move forward with it in our organization. We'd really like to use your plugins, but it would help us a lot if your subversion repository employed tags for releases. Is this something you'd be open to doing?



pet.zip

Aaron Pfeifer

unread,
Feb 16, 2007, 7:36:32 PM2/16/07
to PluginAWeek: Talk
Testing replying to discussion...

> pet.zip
> 351KDownload

Brian Takita

unread,
Feb 17, 2007, 1:59:36 AM2/17/07
to PluginAWeek: Talk
Hello Aaron,

Where you able to read the forwarded message?

Thanks,
Brian

Aaron Pfeifer

unread,
Feb 17, 2007, 8:32:45 AM2/17/07
to pluginaw...@googlegroups.com
Brian,

I apologize, there appear to be problems with Google Groups lately not accepting my messages.  Let's hope this one goes through.

Thanks for posting the detailed issues.  I really appreciate you taking the time to investigate them.  Let's see...

(0) It looks like you have plugin_dependencies 1.2.0 installed.  This is a really old version that was only up temporarily on RubyForge when I was testing publishing gems.  The current version is 0.0.2.  However, I also discovered that the current gem releases won't test either because RubyGems wasn't packaging empty folders.  So you'll have to wait until the next release to get tests on the gems working.

(1), (2), and (3) I'm currently working on these and should have new releases by the end of the weekend.

(4) I absolutely agree.  I wll begin using tags with the next release.

I'll get back to you when the new releases are available.  Thanks again for the report.  Also, if you could use dev.pluginaweek.org to report any other issues, I'd appreciate it.  Thanks!

-Aaron

> > /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies- 1.2.0/lib/plugin_dependencies.rb:33:in

> > `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
> >         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0 /lib/plugin_dependencies.rb:18:in

> > `require'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:309:in
> > `require'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:342:in
> > `new_constants_in'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:308:in
> > `require'
> >         from
> > vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plugins/plugin_with_dependencies/init.rb:1:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-
> > 1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport- 1.4.1/lib/active_support/core_ext/kernel/reporting.rb:11:in

> > `silence_warnings'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../lib/appable_plugins.rb:39:in
> > `load_plugin_without_loaded_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins- 0.0.4/lib/loaded_plugins.rb:57:in

> > `load_plugin'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > `load_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:185:in

Aaron Pfeifer

unread,
Feb 17, 2007, 11:23:14 PM2/17/07
to pluginaw...@googlegroups.com
Brian,

I've just committed http://dev.pluginaweek.org/changeset/440 .  This should address most of the problems you were experiencing.  However, I don't have a test case for the class reloading issue yet to verify whether the changes I made fixed that problem.  I'm booked for the next week, so I unfortunately will not have much time to work on the plugins for the time being.  The 0.1.0 gem releases of the plugins will come out in about 10 days.  In the meantime, if you could verify whether this changeset fixed your issues, I'd appreciate it.  Thanks!

-Aaron

par...@gmail.com

unread,
Mar 6, 2007, 1:03:39 PM3/6/07
to PluginAWeek: Talk
Aaron,

I'm wondering what the status of the class reloading fix is. It's
encouraging us to test more to avoid restarting mongrel, which is
good :), but we'd love to get tis solved.

Thanks!

pt.

On Feb 17, 8:23 pm, "Aaron Pfeifer" <aaron.pfei...@gmail.com> wrote:
> Brian,
>
> I've just committedhttp://dev.pluginaweek.org/changeset/440. This should


> address most of the problems you were experiencing. However, I don't have a
> test case for the class reloading issue yet to verify whether the changes I
> made fixed that problem. I'm booked for the next week, so I unfortunately
> will not have much time to work on the plugins for the time being. The
> 0.1.0 gem releases of the plugins will come out in about 10 days. In the
> meantime, if you could verify whether this changeset fixed your issues, I'd
> appreciate it. Thanks!
>
> -Aaron
>

Aaron Pfeifer

unread,
Mar 18, 2007, 9:19:16 AM3/18/07
to PluginAWeek: Talk
pt,

This was fixed in changest 486 (http://dev.pluginaweek.org/changeset/
486) on edge. It was related to the fact that plugin paths were being
added to Dependencies.load_once_paths when they shouldn't have been.
Sorry for any problems it may have been causing.

-Aaron

Parker Thompson

unread,
Mar 18, 2007, 10:28:04 PM3/18/07
to pluginaw...@googlegroups.com, pivotal-s...@googlegroups.com
rockin'! we'll bang on it tomorrow. thanks,

pt.

Reply all
Reply to author
Forward
0 new messages