Permalink
Browse files

skip haml / sass tests when they fail to load due to stupid bullshit

Both haml and sass have the retarded behavior of trying to read a
VERSION file outside their lib directory. Installing haml or sass
like a sane person (i.e. into a shared lib directory) and they fail
on require with ENOENT.

Ugh.
  • Loading branch information...
1 parent 8a7dd92 commit e1638a43ad3a5c5ea70db56944a5230cc86e537a @rtomayko rtomayko committed Mar 16, 2010
Showing with 11 additions and 0 deletions.
  1. +5 −0 test/haml_test.rb
  2. +6 −0 test/sass_test.rb
View
@@ -1,4 +1,6 @@
require File.dirname(__FILE__) + '/helper'
+
+begin
require 'haml'
class HAMLTest < Test::Unit::TestCase
@@ -88,3 +90,6 @@ def haml_app(&block)
assert_match(/^<!DOCTYPE html PUBLIC (.*) HTML 4.01/, body)
end
end
+rescue
+ warn "#{$!.to_s}: skipping haml tests"
+end
View
@@ -1,4 +1,6 @@
require File.dirname(__FILE__) + '/helper'
+
+begin
require 'sass'
class SassTest < Test::Unit::TestCase
@@ -77,3 +79,7 @@ def sass_app(&block)
assert_equal "#sass {\n background-color: #FFF;\n color: #000;\n}\n", body
end
end
+
+rescue
+ warn "#{$!.to_s}: skipping sass tests"
+end

13 comments on commit e1638a4

Member

sr commented on e1638a4 Mar 16, 2010

I can't remember how many times I did echo 42 > $RIPDIR/VERSION back in the Rip 1.0 era

Contributor

rtomayko replied Mar 16, 2010

Speaking of, I have something to show you sr :) Give me a day or so and I'll ping you about it.

Owner

rkh replied Mar 16, 2010

Wouldn't creating a ticket/patch for Haml appropriate?

Contributor

raggi replied Mar 16, 2010

quite right too.

Contributor

josh replied Mar 20, 2010

you should fork sinatra/haml, fix the issue and have sinatra depend on your fork until haml gets its shit together.

we'll be doing the same for rails. any gem that does stupid shit, we'll not depend on or fork our own rails/ version.

Contributor

rtomayko replied Mar 20, 2010

Problem with that is I don't want to maintain forks for all these gems over time. I'm accumulating a pretty big list. Almost all are reading some kind of VERSION file from the package root. I don't have a better idea, unfortunately.

Contributor

josh replied Mar 20, 2010

Many maintainers are intelligent people that get it. We only have to deal with a few stubborn people like haml.

Fixed 2 out of lib references today:

http://github.com/mperham/memcache-client/commit/c8ec03928eab469ddb77a744a082574f7a9dff73
http://github.com/svenfuchs/i18n/commit/b2f038663b55727ac2327e6f07a46ba5d69d600c

We should be activate about resolving these issues.

Contributor

raggi replied Mar 20, 2010

Something seems wrong about telling people what to do with their file arrangements... I take it you guys are the ones that are right?

Contributor

josh replied Mar 20, 2010

@raggi I don't care how people organize their stuff for development. They can use whatever tools they want. It becomes a problem when their development decisions affect my runtime.

Contributor

raggi replied Mar 20, 2010

it's released as a gem, does it not work as a gem? who's fault is it, really?

Contributor

josh replied Mar 21, 2010

I talked with Nathan today. I think I have a possible fix: http://github.com/nex3/haml/issues/issue/105

Contributor

cldwalker replied Mar 21, 2010

FYI, jeweler encourages keeping VERSION files outside of lib/ as all version-related rake tasks assume such a setup. It wasn't until 1.3.0 that jeweler didn't force this setup on a user.

Please sign in to comment.