I'm trying to write a plugin for ohai. It seems like a pretty straightforward task:
Ohai.plugin(:Uname) do
provides 'uname'
depends 'kernel'
collect_data do
uname Mash.new
uname[:message] = `uname -a`
end
end
To me this looks like the online examples provided by Opscode, O'Reilly and others. But here's what happens when I try to test it:
% irb -rohai
irb(main):001:0> Ohai::Config[:plugin_path] << "."
=> ["/home/ll0359/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/ohai-8.3.0/lib/ohai/plugins", "."]
irb(main):002:0> o = Ohai::System.new
=> #<Ohai::System:0x007fed82e43078 #plugin_path="", #data={}, #provides_map=#<Ohai::ProvidesMap:0x007fed82e42fd8 #map={}>, #v6_dependency_solver={}, #d82e42f38 #controller=#<Ohai::System:0x007fed82e43078 ...>, #v6_plugin_classes=[], #v7_plugin_classes=[]>, #runner=#<Ohai::Runner:0x007fed82e42ec0 #prp:0x007fed82e42fd8 #map={}>, #safe_run=true>>
irb(main):003:0> o.all_plugins
And here's where the fun begins. I get this output, over and over and over:
[2015-05-20T03:13:09+00:00] WARN: Plugin Definition Error: <./ohai_uname.rb>: collect_data already defined on platform default
[2015-05-20T03:13:09+00:00] WARN: [DEPRECATION] Plugin at ./test_ohai.rb is a version 6 plugin. Version 6 plugins will not be supported in future releases....
your plugin to version 7 plugin syntax. For more information visit here: docs.chef.io/ohai_custom.html
(the text on my second line was clipped by my screen but you get the idea)
I've tried running this code with and without the 'depends' line. Same result.
I've tried running this code with and without the Mash line, substituing 'uname uname -a' for the assignment line. Same result.
I've tried running with and without passing ":linux" as a parameter to collect_data. The only difference is I get a warning about collect_data(:linux) already being defined instead of :default.
I've tried renaming the plugin to a random 8 character identifier just in case it was tripping over being called :Uname. Same result.
I've tried passing "uname" (capital and lower) as a parameter to o.all_plugins. Same result.
So my questions are:
Why does ohai (8.3, running under Ruby 2.2.1) think this is a version 6 plugin? I can't see anything in it that would make it look like it's not version 7.
How can I get this working?
Thanks
Note to self: Next time you do this, don't try to test from the directory your plugin is in and add "." to your plugin_path. Moving to a different directory and adding the absolute path to the plugin solved the problem.
I plan to leave this up in case someone else has this happen to them.
Related
I am working on a gem related utility and I have observed strange results using Gem.latest_version_for method. Here are some observations under irb:
irb(main):001:0> Gem.latest_version_for('rails').to_s
=> "5.2.2"
irb(main):002:0> Gem.latest_version_for('gosu').to_s
=> "0.7.38"
Note how the first line, gets the correct version of rails, 5.2.2 as I write this and checking with rubygems.org confirms this. The query for the gosu gem returns 0.7.38 which is wildly wrong. The correct answer should be 0.14.4
I am at a loss to explain what is happening here.
I can confirm that my host is https://rubygems.org and
C:\Sites\mysh
8 mysh>ruby --version
ruby 2.3.3p222 (2016-11-21 revision 56859) [i386-mingw32]
C:\Sites\mysh
9 mysh>gem --version
2.5.2
The latest version available for i386-mingw32 platform is 0.7.38. You'll note this comports with what your ruby version is reported as.
https://rubygems.org/gems/gosu/versions
latest_version_for calls latest_spec_for, which calls Gem::SpecFetcher.spec_for_dependency with only the name of the gem as an argument. spec_for_dependency takes another argument, matching_platform, which defaults to true.
It looks like latest_version_for is scoped to your current platform thru that chain, with the matching_platform default. The gem install command might treat i386/x386 as the same/equivalent and allow them.
spec_for_dependency
if matching_platform is false, gems for all platforms are returned
You should be able to mirror the latest_spec_for method and pass in the multi_platform argument to override. Something like
dependency = Gem::Dependency.new name
fetcher = Gem::SpecFetcher.fetcher
spec_tuples, _ = fetcher.spec_for_dependency dependency, true # true added here
With the excellent help of Jay Dorsey, I think I have made some progress here. What I need to say is too large to fit in a comment and is the actual answer to the question about the odd behavior. Well at least I am pretty sure that it is.
As mentioned above: latest_version_for calls latest_spec_for, which calls Gem::SpecFetcher.spec_for_dependency.
The key is that that method then calls Gem::SpecFetcher.search_for_dependency. This is a long rambling method. I want to focus of one line that occurs after the specs have be obtained:
tuples = tuples.sort_by { |x| x[0] }
This sorts the tuples which are an array of [spec, source] arrays. It sorts them in ascending version/platform (as far as I can tell)
Now we return to the Gem class method latest_spec_for(name) and in particular the line:
spec, = spec_tuples.first
This grabs the first sub-array and keeps the spec and discards the source.
Note that it grabs the first element. The one with the lowest version number. This is normally not a problem because for the vast majority of gems, there will be only one spec present. Not so for the gosu gem. Here there are three due to the fact that gosu contains platform specific code. It seems to grab specs for the two Gem platforms ("ruby" and "x86-mingw32") and also the ruby platform (i386-mingw32).
To test my idea, I created the file glmp.rb (get last monkey patch) Here it is:
# The latest_spec_for(name) monkey patch.
module Gem
# Originally in File rubygems.rb at line 816
def self.latest_spec_for(name)
dependency = Gem::Dependency.new name
fetcher = Gem::SpecFetcher.fetcher
spec_tuples, = fetcher.spec_for_dependency dependency
spec_tuples[-1][0]
end
end
Now I know monkey patching is frowned upon, but for now this is just to test the idea. Here are my results:
36 mysh>=Gem.latest_version_for('gosu')
Gem::Version.new("0.7.38")
C:\Sites\ideas\gem_usage
37 mysh>ls
gem_latest.rb gem_usage.rb glmp.rb
C:\Sites\ideas\gem_usage
39 mysh>=require './glmp'
true
C:\Sites\ideas\gem_usage
40 mysh>=Gem.latest_version_for('gosu')
Gem::Version.new("0.14.4")
While I can use this hack to solve my problem for now, I think I will raise an issue with rubygems bringing up this matter.
I did a fresh install on a MacBook Pro, and installed Mavericks, MacTex, Textmate and Texlive.
I am trying to work with some LaTex documents and I get this error on build:
undefined method `+' for nil:NilClass (NoMethodError).
In previous uses I did not see this error.
Below is the script I think I need to tweak but I do not know how. I found guidance in "Ruby undefined method `+' for nil:NilClass (NoMethodError)", but it does not appear to be applicable.
I am also suspicion of the MacTex download via Chrome, I checked that it was ok in Terminal, ran a checksum, and it was, but the MacTex site advises against using Chrome.
Script with a "problem:"
#!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
# coding: utf-8
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/process"
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/htmloutput"
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/save_current_document"
# To enable the typesetting of unsaved documents, you must change the “Save” setting of
# this command to “Current File” and add the variable TM_LATEX_AUTOSAVE to TextMate's
# Shell Variables preferences. Be warned that your document must be encoded as UTF-8 if
# you excercise this option — becauseTextMate.save_current_document cannot know the file
# encoding you prefer.
TextMate.save_current_document unless ENV["TM_LATEX_AUTOSAVE"].nil?
texMate = ENV["TM_BUNDLE_SUPPORT"] + "/bin/texMate.py"
engine_version = TextMate::Process.run(texMate, "version")
TextMate::HTMLOutput.show(:title => "Typesetting “#{ENV["TM_DISPLAYNAME"] || File.basename(ENV["TM_FILEPATH"])}”…", :sub_title => engine_version) do |io|
TextMate::Process.run(texMate, 'latex', '1', :interactive_input => false) do |line|
io << line
end
end
::Process.exit($?.exitstatus || 0) # exitstatus is nil if our process is prematurely terminated (SIGINT)
Any help would be great, thanks.
The error you received happens when you try to use the method + on nil:
nil + 'something'
In your code the '+' sign appears in 4 places:
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/process"
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/htmloutput"
require ENV["TM_SUPPORT_PATH"] + "/lib/tm/save_current_document"
...
texMate = ENV["TM_BUNDLE_SUPPORT"] + "/bin/texMate.py"
Which means that one of either ENV["TM_SUPPORT_PATH"] or ENV["TM_BUNDLE_SUPPORT"] returns nil.
The ENV construct reflects the content of your machine's environment variables, therfore you should make sure the environment variables TM_SUPPORT_PATH and TM_BUNDLE_SUPPORT are set.
Problem solved. I deleted Textmate and then relied on Hazel to delete all affiliated files. I used TexLive to update all packages, ... just an overhaul. Following Mactex guidance using Safari for all future downloads, including the new download of Textmate, Installed Textmate, then followed this guidance, How and "Why to use TextMate for LaTeX," by Kelle, http://www.astrobetter.com/how-and-why-to-use-textmate-for-latex/#comment-595219 ... by the way excellent blog for help with Teaching. I then did a restart, which may not be necessary. Works wonderfully. I cannot comment on the value of the tweaking above, Red Herrings abound, the extent of the absenteeism may have indicated the initial installation was off (a guess). Thanks
I had a similar problem, all the builts stoped working after I cleaning up some bundles that I do not need and installing some new ones. The solution was that I deinstalled the Bundle "Bundle Support", even if it says "no not uninstall" in the description.
Reactivating "Bundle Support" solved this issue for me.
I have a question for the Ruby and Chef hackers.
I have very limited knowledge of Chef and even less on Ruby programming language, however, I need to implement on Chef (chef-solo) something similar to "augeas" (which works with Puppet, but here I need a solution for Chef).
I got the example code below but it's not working and I am now for a few days trying to figure out what is wrong.
Basically I need to be able to select specific strings in a text file and modify these values. I could use sed but perhaps I can do it in a more elegant way using the ruby_block from Chef.
Please let me know what can be possibly wrong with the code below. Why is my /etc/hosts not being updated with new values?
Always when I re-run chef-solo, I get the following error:
NoMethodError
-------------
undefined method `chef' for Chef::Resource::RubyBlock
Thanks for your help.
Follows my default.rb file:
ruby_block "edit etc hosts" do
block do
rc = Chef::Util::FileEdit.new("/etc/hosts")
rc.search_file_replace_line(
/^127\.0\.0\.1 localhost$/,
"127.0.0.1 #{new_fqdn} #{new_hostname} localhost"
)
rc.write_file
end
end
Add this line as the first line of your ruby block:
require 'chef/util/file_edit'
According to your case, you should use the cookbook hostsfile:
hostsfile_entry '127.0.0.1' do
hostname new_hostname
aliases [new_fqdn]
comment 'Append by Recipe X'
action :append
end
It shouldn't be too hard to get Augeas to work with Chef. Augeas is a C library, and Puppet simply uses its Ruby bindings. You just need to make use of these bindings in Chef.
There is a PoC Augeas resource provider for Chef here: https://github.com/craigtracey/augeas.
Note: http://lists.opscode.com/sympa/arc/chef/2013-02/msg00337.html mentions Augeas integration into Chef, but apparently the participants misunderstand Augeas as they mention idempotency issues and deltas. Most uses of Augeas don't lead to managing deltas, but desired states.
I would like to make HTTP requests from Rails code running on top of JRuby.
How can I make it to re-use http.proxyHost, http.proxyPort and http.nonProxyHosts settings, given to JVM running it ?
To pass JVM flags through JRuby, use -J.... In this case:
jruby -J-Dhttp.proxyHost=foo -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts="*.bar.com" ...
This is explained in JRuby's help text.
-J[java option] pass an option on to the JVM (e.g. -J-Xmx512m)
use --properties to list JRuby properties
run 'java -help' for a list of other Java options
I have had the same issue. I found that java or net::http doesn't obey the nonProxyHosts option. The best way to get around this is to modify the ENV_JAVA settings to account for this.
The steps I took to ensure nonProxyHosts was used were the following:
1) JAVA_OPTS="-Dhttp.proxyHost=192*** -Dhttp.proxyPort=1234 -Dhttp.nonProxyHosts=local|127.0.0.1"
OR
1) JRUBY_OPTS="-J-Dhttp.proxyHost=192*** -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts=local|127.0.0.1"
Keep in mind that at least for java1.7 the nonProxyHosts should not have quotations see here.
Now I find that either net::http or java itself doesn't actually honour the nonProxyHosts option.
However you can get around this by doing the following in JRuby
a = URI("http://someurl")
Net::HTTP.new(a).proxy?.should == true
regex = /$#{ENV_JAVA["http.nonProxyHosts"]}/ #dollar needed to behave as expected
if a.hostname.match(regex)
ENV_JAVA["http.proxyHost"]=nil
end
Net::HTTP.new(a).proxy?.should == false
Hope that helps.
Currently I'm only able to say:
test.using(:scalatest)
Buildr documentation says that class Buildr::Scala::ScalaTest supports the following options:
:properties - Hash of system properties available to the test case.
:environment - Hash of environment variables available to the test case.
:java_args - Arguments passed as is to the JVM.
But those are parameters to test cases and JVM only, not to ScalaTest ?
D:\>buildr --version
C:/Ruby186/lib/ruby/gems/1.8/gems/buildr-1.4.4-x86-mswin32/lib/buildr/java/packaging.rb:62: warning: parenthesize argument(s) for future version
Buildr 1.4.4
See my discussion on Twitter with Alex: http://twitter.com/#!/boia01/status/27605157764145153
If you still need this, please open an issue in Buildr's bug tracker, and we'll address it :)