We've found too many issues with having metric_fu and its minions as our development dependency and it's easier to just drop them then to figure out how to fix it. If one wants to run code quality checks on the codebase it's obviously still possible but you need to handle deps instalation on your own. What were the problems? 1) with metric_fu along with roodi etc in the gemfile bundling takes forever (ok, it takes about 40-60 minutes) 2) if we leave only metric_fu as the dep (which depends on roodi etc. anyway) we will get latest versions of the gems which unfortunatelly results with a weird error when running semipublic specs so we need to pin the versions which gets us back to the problem #1
For some reason, bundler always seems to hang with almost 100% cpu at the following step: Fetching source index for http://rubygems.org/ This happens on both 1.8.7 and 1.9.2 when trying to bundle install into a fresh rvm gemset. I'm not sure why this is, if it's a bug with our Gemfile or a bug in rails or bundler. It's be cool if someone could try to reproduce so that we can get down to the real error.
1) Issue the following commands to get a fully functional development environment including datamapper and rails up and running within a minute gem install bundler # if this is new for you bundle install rake spec Now that was easy, wasn't it? 2) Dropped the dependency on actionmailer since there's really no need for it (This will most probably need updates to http://github.com/snusnu/rails-templates though, because a default generated rails app gets generated with config values that rely on the presence of actionmailer. 3) We also don't require activemodel explicitly anymore. This is because active_model already does that for us. No need specifying dependencies twice. Thx to Alex Mankuta and Dan Kubb for noticing the dependency weirdness. 4) Added instructions on how to get a development environment up and running to the README