Hey folks, I have merged the patches that make dm-core and all of dm-more compatible with both active_support-3.0.0.beta1 and extlib into both dm-core and dm-more master branches. Also, dm-core and all dm-more gems now have a Gemfile, so setting up a development environment to work on DM itself is dead simple now.
Before anything else, I should say that this is only an internal change and should not affect you as an application developer. If you're using DM with merb for example, everything will continue to work the way it did because DM still knows how to fall back to using extlib in case it couldn't require the necessary active_support features. This is different from before when DM had a hard dependency on extlib. We removed this dependency, and instead try to require active_support features first. If this fails, we fall back to requiring extlib. Code that we need from extlib that is not present in active_support has been pulled into dm-core to support running with active_support only, without any needs for requiring extlib. This is necessary because these two libs don't really play well together. A nice effect of using active_support only is that it makes DM compatible with the rails3 codebase. Previously, requiring both active_support and extlib could lead to weird problems because the two gems sometimes provide overlapping method definitions. This also means that from now on, DM will prefer active_support and we plan to make more use of active_support features where that makes sense. Eventually, extlib compatibility will be dropped completely, but this probably won't happen any time soon. It definitely won't happen before either merb decides to use active_support too, or takes other measures to improve compatibility. We definitely don't want to break existing merb applications. So while for application developers this change mostly means that they can start to use DM along with dm-rails [1] and the rails-templates [2] to build rails3 applications, it means a few more things for people working on either DM itself or any kind of DM plugin. First of all, setting up a development environment has never been that easy. Clone the repo and run bundle install --without quality # i know it sounds weird, but bear with me to install dm-core or any of the dm-more gems along with all its dependencies. This works thanks to the awesomeness that is bundler [3], so you'd obviously need to "gem install bundler" if you haven't already done so. Bundling with the above command will give you a development environment that uses active_support-3.0.0.beta1 from rails master branch since this is the default now. If you want to include extlib instead of active_support in your bundle (because you want/need/should run the tests for extlib too) issue EXTLIB=true bundle install --without quality Note that you need to run both these "bundle install" commands at least once in order to be able to run specs with either active_support or extlib. This will make sure that both gems are part of the bundle (but only one will be activated at a time, depending on the EXTLIB environment variable) To run the specs you will need to make sure that you're using the bundled environment too. Issuing bundle exec rake spec # or EXTLIB=true bundle exec rake spec will run the specs with either active_support or extlib. The above instructions work for dm-core and any gem that is part of dm-more. The toplevel Rakefile in the dm-more project now has a few new tasks too. rake bundle:install # Runs 'bundle install --without quality' for all gems in dm-more rake bundle:install:quality # Runs 'bundle install' for all gems in dm-more rake gemspec # Generate gemspecs for all gems in dm-more Additionally, the toplevel "rake spec" task now uses "bundle exec" under the hood by default which means that once you ran "rake bundle:install" in the dm-more directory, you can run "rake spec" to run specs for all bundled dm-more gems. The rake tasks all accept an EXCLUDE=true env variable too, which can be useful if for example you want to skip running specs for (a comma separated list of) some gems. This should be enough to get a working datamapper development environment up and running. So now that DM decided to prefer active_support, we'd really appreciate seeing the community of plugin authors to catch up on these new developments. It'd be cool to see as many plugins as possible supporting DM's decision by implementing the double compatibility approach too. It's not hard to do so at all! Have a look at the (meat of the) patch at [4] and [5] to see what's basically needed to support both gems. I should not forget to mention the original motivation behind this change. Of course rails3 was a big factor. We definitely want to support developing apps with DM on that platform as smoothly as possible. But there are also other benefits. The community developing active_support is just so much bigger, and the code has probably seen more real world usage/tests than extlib. Also, the latest refactorings in the active_support-3.0 series made it cherry pickable, which means that we can safely only require the parts we need, without the need to pull in everything, as was the case with previous versions. These, along with the fact that it contains quite some other goodies that could help clean up some parts of DM, made us think that it's the best choice to make for DM in the long term. cheers snusnu [1] http://github.com/datamapper/dm-rails [2] http://github.com/snusnu/rails-templates [3] http://github.com/carlhuda/bundler [4] http://is.gd/aVhHV [5] http://is.gd/aVhDp -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to datamap...@googlegroups.com. To unsubscribe from this group, send email to datamapper+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
