Mr Bones is a handy tool that builds a skeleton for your new Ruby
projects.
The skeleton contains some starter code and a collection of rake tasks
to
ease the management and deployment of your source code. Mr Bones is not
viral – all the code your project needs is included in the skeleton (no
gem dependency required).
== FEATURES/PROBLEMS:
Mr Bones provides the following rake tasks:
clobber # Remove all build products
doc # Alias to doc:rdoc
doc:rdoc # Build the rdoc HTML Files
doc:release # Publish RDoc to RubyForge
doc:rerdoc # Force a rebuild of the RDOC files
doc:ri # Generate ri locally for testing
gem # Alias to gem:package
gem:debug # Show information about the gem
gem:gem # Build the gem file
gem:install # Install the gem
gem:package # Build all the packages
gem:release # Package and upload to RubyForge
gem:repackage # Force a rebuild of the package files
gem:uninstall # Uninstall the gem
manifest:check # Verify the manifest
manifest:create # Create a new manifest
notes # Enumerate all annotations
notes:fixme # Enumerate all FIXME annotations
notes:optimize # Enumerate all OPTIMIZE annotations
notes:todo # Enumerate all TODO annotations
spec:rcov # Run all specs with RCov
spec:run # Run all specs with basic output
spec:specdoc # Run all specs with text output
test:rcov # Run rcov on the unit tests
test:run # Run tests for run
The rake tasks in the Mr Bones framework can be found in the “tasks”
directory. Add your own tasks there when you need more functionality.
== SYNOPSIS:
To create a new “Get Fuzzy” project:
bones get_fuzzy
If a new release of Mr Bones comes out with better features the “Get
Fuzzy”
project will need to be updated:
bones --update get_fuzzy
And if you ever get confused about what Mr Bones can do:
bones --help
== REQUIREMENTS:
Mr Bones does not have any “requirements”, but if you do not have the
following gems installed you will not get all that Mr Bones has to
offer.
rubyforge - for easy gem publishing to rubyforge.org
Looks very col. However, after installing the gem, I tried it out and
got this:
james@james06:/tmp$ bones FOOBAR
/usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.1/lib/spec/runner/options.rb:216:in
`files_to_load’: File or directory not found: manifest:create
(RuntimeError)
It does create the project directory, though.
However, if I cd to that folder and run
$ rake manifest:create
I get that same error.
In fact, this seems to happen with other rake tasks as well. For
example:
james@james06:/tmp/FOOBAR$ rake clobber
(in /tmp/FOOBAR)
/usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.1/lib/spec/runner/options.rb:216:in
`files_to_load’: File or directory not found: clobber (RuntimeError)
–
James B.
“The greatest obstacle to discovery is not ignorance, but the illusion
of knowledge.”
Mr Bones is a handy tool that builds a skeleton for your new Ruby projects.
The skeleton contains some starter code and a collection of rake tasks to
ease the management and deployment of your source code. Mr Bones is not
viral – all the code your project needs is included in the skeleton (no
gem dependency required).
Same idea, but different implementation. Mr Bones is a bit simpler
than Rabal. The main difference is (1) in how much of a skeleton is
created (Mr Bones is a smaller skeleton) and (2) how the rake tasks
are managed. Mr Bones does everything by setting project parameters in
the top-level Rakefile. Rabal generates tasks specific to a particular
project.
Or, for that matter, how is this different than newgem, hoe, echoe,
and the others? Not a critical question (variety isn’t bad at all),
but I’m just wondering if there’s an advantage over those libraries.
Looks very col. However, after installing the gem, I tried it out and
got this:
james@james06:/tmp$ bones FOOBAR
/usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.1/lib/spec/runner/options.rb:216:in
`files_to_load’: File or directory not found: manifest:create (RuntimeError)
Just fixed the bug and release a 1.1.1 version.
I was requiring the top-level RSpec file, “spec.rb”, and that has an
“at_exit” handler that tries to run the tests specified on the command
line. This just happens to be whatever rake task you were trying to
run, and it complains that it can’t find that file.
I was requiring the top-level RSpec file, “spec.rb”, and that has an
“at_exit” handler that tries to run the tests specified on the command
line. This just happens to be whatever rake task you were trying to
run, and it complains that it can’t find that file.
Or, for that matter, how is this different than newgem, hoe, echoe,
and the others? Not a critical question (variety isn’t bad at all),
but I’m just wondering if there’s an advantage over those libraries.
Regarding the rake tasks, Mr Bones is intended to put everything in
the skeleton. Contrast this to hoe and echoe where you are relying on
an external gem. With Mr Bones you can twiddle the tasks if they don’t
do what you need / like / desire. That is a little more difficult to
do with the others.
Mr Bones has the upgrade flag for when you want to update your tasks.
You have to update all your projects individually. Hoe and echoe
simplify this since they are included in all your projects – update
those guys and all your projects are running the latests and greatest
(which might or might not be what you want).
Anyway, Mr Bones is a little more work, but it provides more
flexibility for my needs. Just thought I would share.
Same idea, but different implementation. Mr Bones is a bit simpler
than Rabal. The main difference is (1) in how much of a skeleton is
created (Mr Bones is a smaller skeleton) and (2) how the rake tasks
are managed. Mr Bones does everything by setting project parameters in
the top-level Rakefile. Rabal generates tasks specific to a particular
project.
Tim! I see what you’ve been doing on your vacation. Dang you, getting
Mr. Bones out there before I can refactor Rabal. I love the name.
I’m sure Tim and I will have several conversations :-). We do happen to
frequent the same coffee shop on an exteremely regular basis.
Oh, and Ben, look for a refactoring of Rabal in the coming months. I
have a couple more ideas I need to work with.
I was requiring the top-level RSpec file, “spec.rb”, and that has an
“at_exit” handler that tries to run the tests specified on the command
line. This just happens to be whatever rake task you were trying to
run, and it complains that it can’t find that file.
Fixed now.
after running merb generator i get similar error.
/Library/Ruby/Gems/1.8/gems/rspec-1.1.1/lib/spec/runner/options.rb:
216:in `files_to_load’: File or directory not found: info
(RuntimeError)
james@james06:/tmp$ bones FOOBAR
/usr/local/lib/ruby/gems/1.8/gems/rspec-1.1.1/lib/spec/runner/options.rb:216:in
`files_to_load’: File or directory not found: manifest:create (RuntimeError)
Just fixed the bug and release a 1.1.1 version.
hm, seems to be still a problem, even using rspec 1.1.2:
/opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.2/lib/spec/runner/options.rb:216:in files_to_load': File or directory not found: test:units (RuntimeError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.2/lib/spec/runner/options.rb:210:ineach’
On Jan 16, 2008, at 3:35 AM, Florian Ebeling wrote:
/opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.2/lib/spec/runner/
options.rb:216:in files_to_load': File or directory not found: test:units (RuntimeError) from /opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.2/lib/spec/runner/ options.rb:210:ineach’
If you have the following line anywhere in your source code
require ‘spec’
RSpec is going to load an at_exit handler that will try to run RSpec
specifications. I had this require line in version 1.1.0 of Mr Bones.
The release of Mr Bones 1.1.1 fixed that bug (Mr Bones is now up to
1.3.0 by the way).
Grep through you code and see if something has the line “require
‘spec’”. That is where the problem is coming from.
at_exit do
puts “foo”
end
at_exit do
puts “bar”
end
at_exit do
puts “baz”
end
end of existing code,
monkey patch begins below…
BEGIN {
def at_exit(&block)
if $at_exit_handlers # or make this local to BEGIN and use
define_method
$at_exit_handlers << block
else
$at_exit_handlers = [block]
super do
while block = $at_exit_handlers.pop
block[$at_exit_handlers]
end
end
end
end
}
at_exit do |remaining|
remaining.delete_if do |block|
eval(“LINE”, block) == 1 # or use FILE
end
puts “deleted foo handler”
end
Sounds like a good implementation. I’ll test it later and let you know
how I feel.
I’m of the persuasion that likes very, very, very minimal overhead for
something simple. Currently, my primary Gem project is Halcyon and
with a single Rakefile I get by with packaging, locally installing,
uninstalling, generating RDocs, etc. All that is required is my time
to fill out the project information in the Rakefile and the directory
structure to be sane.
Like I said, I’ll take a look at it and see if it satisfies my
ultra-slim mentality.
Matt
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
