On Tue, Jun 14, 2011 at 12:27:44PM -0700, Jason King wrote:
> My mistake - I was reading between the lines and thought you were looking
> for a network-less deployment solution.
I've figured out the source of my difficulties. It seems to be a cultural
difference that caught me off-guard. From Perl and C, I'm accustomed to the
following workflows:
# C on Unixen
tar -zxf foo-1.00.tar.gz
cd foo-1.00
./configure
make
make test # when "test" target defined
sudo make install
# Perl
tar -zxf Foo-1.00.tar.gz
cd Foo-1.00
perl Makefile.PL
make
make test # "test" target always defined for Perl module distros
sudo make install
Naturally, you have to build/install any runtime prerequisites first.
However, you are generally able to run the test suite -- indeed, you are
*expected* to run the test suite -- prior to "make install" when performing
manual installation.
In the RubyGems packaging system, it appears that running tests is considered
a "development" activity. The default behavior for "gem install foo" seems to
be to install all prerequisites for "foo" without running their test suites,
and then to install "foo" itself without running its test suite. The behavior
is akin to that of apt-get, rpm, etc.
This is very different from how the CPAN client -- Perl's default packaging
system -- works. When you run "cpan install Foo", the default behavior is to
run all test suites. If the test suite for any of Foo's prerequisites fails,
installation aborts (though any prerequisites in the chain which had already
been installed successfully will remain); if the test suite for Foo itself
fails, installation aborts.
You can override the CPAN client's behavior by specifying a "force", which
means "run the test suite but install even if it fails":
cpan -f install Foo
However, this is something you would do only in extraordinary circumstances,
like when you know exactly what tests are failing and why those failures won't
cause problems for you.
I can see how omitting the test phase by default when performing gem
installations affords Ruby developers a certain amount of convenience. You
don't have to wait for the tests to run, and you aren't bothered to chase down
problems with flaky dependencies.
However, I would expect that skipping tests causes predictable, negative
consequences for Ruby devs as well in terms of portability problems. Debian's
apt-get can get away with not running tests because the systems it is
installing onto are uniform. While Ruby succeeds in hiding many of the
differences between operating systems, it can only do so much. (File locking
immediately springs to mind as an area where operating systems vary widely.)
By installing without testing, it is left for the end user to debug problems
in their application which would have been caught by unit-test failures.
Is my assessment of the situation correct? If so, I'm surprised, given the
strong traditions of testing within the Ruby world. It's reasonable to expect
a gem's author to ensure that the test suite passes on one or more systems
before publishing, but it's not reasonable to expect them to test on *all*
possible systems. And if a gem's author has gone to all that trouble to write
tests, it seems a shame to squander that effort and saddle downstream
developers with debugging portability problems.
Does RubyGems offer any accommodations for a crank like me who wants to see
tests pass before letting an installer dump a gem onto my system? I'm
guessing "no", because I immediately ran into a circular dependency problem
between RSpec and Bundler that would have forced me to install one or the
other first without running tests.
Marvin Humphrey
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
