Slightly Technical

I was introduced to the combination of RVM and Bundler while working with my friend James on a project earlier in the year. It’s a nice combination of Ruby tools which offers developers a way to keep tabs on the Ruby gems they are using in a project and to avoid conflicts, or the accidental use of other versions of those gems, when they are actively developing or deploying their work. Typically these projects might be Ruby on Rails-based web applications but although ‘Rails’ is often accidentally substituted for ‘Ruby’ there is no reason why Bundler + RVM should be any less useful outside of Rails.

I found the post he pointed out, by Mike Lindsaar, very helpful to keep me enthused and get me trying things out but I also found the concept was still hard to grasp. Although both Bundler and RVM are adequately documented, somehow their example-driven documentation doesn’t quite make things clear at first/second reading. So here’s a quick synopsis which I’ve written to help my own understanding.

RVM

RVM (Ruby Version Manager) is a tool that creates named Ruby builds and named sets of gems. It lets you swap between these builds and sets at will.

Use RVM to build a named Ruby, then use RVM commands to modify the environment in your current shell so it will use that build instead of the system default. Likewise, once you have created a named gemset with RVM, you can then use RVM commands to bring the gems in that gemset into use in your shell. They will be made available to whichever Ruby is currently accessible using the information in your environment.

An .rvmrc file lets RVM automatically switch the Ruby build and gemset without human intervention.

Bundler

Bundler is a gem that installs and uninstalls other gems following a list you maintain.

The list centralises the information about which gems are needed to allow a given project’s Ruby code to run. It tidies up some loose ends and hard-to-manage conflicts by allowing you to specify exactly which gem version is needed to run the code, so that if there’s a feature that is missing from earlier gem versions or removed from later ones you can keep using the version you need even when it is obsolete.

The Gemfile, the list that Bundler works with, is plaintext and therefore version-controllable. It sits naturally at the root of the project.

Putting them together

RVM is great on its own, because as you swap between projects in daily work on your own machine you can swap between different Ruby versions and different sets of gems instantly. You are protected from updates to a gem on the system breaking things in your projects and you can retrospectively introduce an RVM gemset to sort things out if that does happen. That should make it really useful for anyone developing gems or dealing with legacy code issues.

The Bundler gem is required by Rails 3 itself [‘baked in’ as I am sure its developers would say, with tongues in their cheeks], and I guess that’s because it was the Rails use-case itself that caused Bundler to be written. So either tool is useful alone. The point of Mike’s post is that by coupling the two together you get a really nice combination. Here’s what you can do.

1. RVM to create a named Ruby build, if desired

2. RVM to create a named gemset (probably named for the project)

3. .rvmrc file in project root to ensure that when code is executed in the project’s directory tree it’s run with the right Ruby and gemset

4. Gemfile in project root to specify gems required for the codebase (remember this is version-controllable)

5. Bundler to read the list of gems and install them; the gems are installed within the environment that’s active, so they’ll be installed within the RVM gemset for the project and not elsewhere

Of course to benefit from all this on your own machine with multiple projects is one thing; RVM will not seem nearly as necessary if the project code is deployed to a dedicated server with no other web applications running on it. But not all deployments look like that.

I think I have this all right; comments welcome of course.

I’m getting excited about a conference in planning for January 2011 at St Bride Library in London.

It’s part of St Bride Library’s series of one-day events, intended to be both approachable and affordable. This particular conference is The Design of Understanding, and it will be curated by Max Gadney.

A glance at the speakers lined up so far gives a good idea of the quality we can expect from the day’s talks. If you’re into user experience, graphics, information design and data, and can make it to London for 28 January, be sure to be there.

I struggled for quite a long time to get the MacPorts libxslt module for python 2.4 (required for a legacy project) to install. A lot of searching turned up many leads but no bug report, and this is a low-priority situation for port maintainers because python 2.4 is now very out of date. This is what I did.

Installed python24.

Installed py-libxslt.

At the end of the port install process for py-libxslt I received an error message. A read of the log said:

[...]
:debug:activate activate phase started at Tue Jul  6 11:48:03 BST 2010
:debug:activate Executing org.macports.activate (py-libxslt)
:error:activate Target org.macports.activate returned: Registry error: py-libxslt 2.6.21_0 not registered as installed.
:debug:activate Backtrace: Registry error: py-libxslt 2.6.21_0 not registered as installed.
    while executing
"registry::installed $name $v"
    (procedure "_check_registry" line 38)
    invoked from within
"_check_registry $name $v"
    (procedure "portimage::activate" line 58)
    invoked from within
"registry_activate $name "${version}_${revision}${portvariants}" [array get user_options]"
    (procedure "portactivate::activate_main" line 6)
    invoked from within
"$procedure $targetname"
:info:activate Warning: the following items did not execute (for py-libxslt): org.macports.activate
:notice:activate Log for py-libxslt is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_python_py-libxslt/main.log

This indicated that everything was happily built, but the software was not installed in its correct directory for some reason (not evident in the log). I found it difficult to get my head around the way MacPorts works in the time available and establish what went wrong. So I short-circuited the problem by copying the software (libxslt.py) from the MacPorts build directory into the lib directory where it should have been put (/opt/local/lib/python2.4/site-packages).

This will mess up MacPorts’ information about what is installed, so other python 2.4 dependent things might conceivably not be installable. Equally it might be tricky to remove the /opt/local/lib/python2.4/site-packages directory using MacPorts commands without forcing it. But meanwhile I have a working python libxslt module and that’s what I needed.

I’ve been playing with Osmarender in an effort to generate vector map artwork for a design project. The map needs to have different visual styling from the way Open Streetmap looks and also will lack things like street names and bus stops which are not relevant outside the navigation context for which OSM’s maps are primarily intended.

The Osmarender SVG forms one step of the conversion process from raw information collected on the ground and the presentation of maps online at openstreetmap.org. For me, one problem has been the close tailoring of this transformation to the visual style used in Open Streetmap’s map images. Various ruses are used to create an image that suits a web interface; these are not so beneficial when working with vector data because they tend to exploit the fact that the final images will be seen at a pre-determined and fixed resolution.

After deleting quite a lot of stuff, and latterly separating the land use, waterways, routes and labels, I think I might be getting somewhere. I will post the modified rules files and stylesheet if I do make things work. I can see that I will still have to tidy up the files in a vector editor at the end – but of course OSM is permanently under revision, which implies errors in the data as well as acknowledging that features on the ground will change.