EasyInstall Package Provider crashes

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 0.9.16
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:

    Ubuntu 10.04, Ruby 1.8.7 (2010-01-10 patchlevel 249)

Description

Defining a package resource with the easy_install provider like so

package "some_package" do
  action :install
  provider Chef::Provider::Package::EasyInstall
end

causes a crash with the following backtrace:

/usr/lib/ruby/1.8/chef/resource.rb:144:in `method_missing': undefined method `module_name' for Chef::Resource::Package (NoMethodError)
from /usr/lib/ruby/1.8/chef/provider/package/easy_install.rb:65:in `module_name'
from /usr/lib/ruby/1.8/chef/provider/package/easy_install.rb:76:in `load_current_resource'
from /usr/lib/ruby/1.8/chef/resource.rb:394:in `run_action'
from /usr/lib/ruby/1.8/chef/runner.rb:53:in `run_action'
from /usr/lib/ruby/1.8/chef/runner.rb:89:in `converge'
from /usr/lib/ruby/1.8/chef/runner.rb:89:in `each'
from /usr/lib/ruby/1.8/chef/runner.rb:89:in `converge'
from /usr/lib/ruby/1.8/chef/resource_collection.rb:94
...
many more lines

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
James Brinkerhoff added a comment -

Issue appears to be present in 0.10.0 as well, my package resource looks exactly the same.

Show
James Brinkerhoff added a comment - Issue appears to be present in 0.10.0 as well, my package resource looks exactly the same.
Hide
Permalink
Guilhem Lettron added a comment -

https://github.com/opscode/chef/pull/310

Show
Guilhem Lettron added a comment - https://github.com/opscode/chef/pull/310
Hide
Permalink
Steven Danna added a comment -

Thanks for working on this! Could you update your pull request with tests for this feature?

In the long run we would like to deprecate the use of "provider" (at least in a software) since it reveals implementation details. Rather than using "provider" creating a shortcut resource (like the bash resource) should be preferred.

Show
Steven Danna added a comment - Thanks for working on this! Could you update your pull request with tests for this feature? In the long run we would like to deprecate the use of "provider" (at least in a software) since it reveals implementation details. Rather than using "provider" creating a shortcut resource (like the bash resource) should be preferred.
Hide
Permalink
Guilhem Lettron added a comment -

Hello,

I'm sorry but I don't know how to do this sort of test (I'm not a experimented ruby dev).
It will take some time to me to learn/test/push. And, for the moment, easyinstall is always broken :/

I will comment if I have enough time to do this.

Best regard.

Show
Guilhem Lettron added a comment - Hello, I'm sorry but I don't know how to do this sort of test (I'm not a experimented ruby dev). It will take some time to me to learn/test/push. And, for the moment, easyinstall is always broken :/ I will comment if I have enough time to do this. Best regard.
Hide
Permalink
Guilhem Lettron added a comment -

I change this as resolved because it resolve this critical bug.

For now, easy_install isn't usable. Many Cookbook can't work (and can't be used) without this. And I must patch all my chef-client and this is quite long...

I doesn't find any tests in the chef repo. Maybe I'm not good with this, but if today there is tests they must be some crap.

Please merge this patch for the good of all of us

Best regards.

Show
Guilhem Lettron added a comment - I change this as resolved because it resolve this critical bug. For now, easy_install isn't usable. Many Cookbook can't work (and can't be used) without this. And I must patch all my chef-client and this is quite long... I doesn't find any tests in the chef repo. Maybe I'm not good with this, but if today there is tests they must be some crap. Please merge this patch for the good of all of us Best regards.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

The relevant existing tests are in chef/spec/unit/provider/package/easy_install_spec.rb.

Show
Bryan McLellan [Opscode] added a comment - The relevant existing tests are in chef/spec/unit/provider/package/easy_install_spec.rb.
Hide
Permalink
Bryan McLellan [Opscode] added a comment -

Thanks for the patch Guilhem.

The workaround for this is:

easy_install_package "some_package" do
  action :install
end

The issue here is that the easy install resource has different attributes than the package resource.

As the project grows, it is very important that we add tests when there is a regression to ensure that the functionality of the code is protected. At a minimum we request a test to cover the regression that is fixed, which is a small step toward adequate test coverage where there currently is not.

Show
Bryan McLellan [Opscode] added a comment - Thanks for the patch Guilhem. The workaround for this is: easy_install_package "some_package" do action :install end The issue here is that the easy install resource has different attributes than the package resource. As the project grows, it is very important that we add tests when there is a regression to ensure that the functionality of the code is protected. At a minimum we request a test to cover the regression that is fixed, which is a small step toward adequate test coverage where there currently is not.
Hide
Permalink
Guilhem Lettron added a comment -

Thank you Bryan, your are my hero

For the unit tests, I agree with you.. badly, I don't know how to do this very well (I need more practice of ruby) and I don't have enough time this days.

I will try your workaround today.

Best regards.

Show
Guilhem Lettron added a comment - Thank you Bryan, your are my hero For the unit tests, I agree with you.. badly, I don't know how to do this very well (I need more practice of ruby) and I don't have enough time this days. I will try your workaround today. Best regards.

People

  • Assignee:
    Guilhem Lettron
    Reporter:
    Frederik Fix
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: