stick's corner

Today I needed to implement “human sort” for a list of distributions we support in the Open Build Service. I wanted to sort them alphabetically but at the same time the newest ones at the top. I ended up with the following code:

module Enumerable
  def version_sort
    sort_by { |key,val|
       key.gsub(/_SP/,'.').gsub(/_Factory/,'_100').split(/_/) \
          .map { |v| v =~ /\A\d+(\.\d+)?\z/ ? -(v.to_f) : v.downcase }
    }
  end
end

@distros = [
  'openSUSE_Factory_PPC',
  'CentOS_6',
  'openSUSE_11.4',
  'RHEL_4',
  'Mandriva_2010',
  'RHEL_5',
  'Debian_5.0',
  'SLE_10',
  'Ubuntu_9.04',
  'Fedora_14',
  'RHEL_6',
  'Ubuntu_11.04',
  'SLE_11',
  'Mandriva_2009.1',
  'CentOS_5',
  'openSUSE_11.3',
  'Debian_6.0',
  'openSUSE_11.1_Evergreen',
  'Ubuntu_10.04',
  'ScientificLinux_6',
  'openSUSE_Factory',
  'Ubuntu_10.10',
  'SLE_11_SP1',
  'Fedora_15',
  'Ubuntu_8.04',
  'Ubuntu_9.10',
  'Mandriva_2010.1',
]

@distros.version_sort.each{ |v|
  puts v
}

which produces this list:

CentOS_6
CentOS_5
Debian_6.0
Debian_5.0
Fedora_15
Fedora_14
Mandriva_2010.1
Mandriva_2010
Mandriva_2009.1
openSUSE_Factory
openSUSE_Factory_PPC
openSUSE_11.4
openSUSE_11.3
openSUSE_11.1_Evergreen
RHEL_6
RHEL_5
RHEL_4
ScientificLinux_6
SLE_11_SP1
SLE_11
SLE_10
Ubuntu_11.04
Ubuntu_10.10
Ubuntu_10.04
Ubuntu_9.10
Ubuntu_9.04
Ubuntu_8.04

Nifty, right? The idea is simple. I use the sort_by function which pre-computes the values that are later compared. I replace some special values like “_Factory” or “_SP”, because I want “Factory” to be the newest (100 is higher than any other openSUSE version) and “11_SP1″ to behave exactly like “11.1″. Then I split the key using the “_” delimiter and turn any string in form “digit” or “digit.digit” to float number. I change the sign, because I want versions to be sorted in the reverse direction. Good thing is that Ruby operator <=> works on arrays also, so I’m done with key modifications and the sort does the rest …

PS: I used |key,val| in sort_by block because I want to use this function also to sort hashes by their key. This way it works both for arrays and hashes with any further modifications.

If you are closely following Ruby development and especially the situation around ruby gems, you might already know of Gemcutter. It is a new service, which provides a very easy way how to publish gems and also a good API to deal with them. It is not trying to replace RubyForge as whole, just its gem hosting (+ now defunct GitHub gem hosting) and will soon become the central and the only place for Ruby gems. The whole site is MIT licensed and the code is available on GitHub.

During the winter holidays I wrote a simple script which utilizes the Gemcutter API and prints versions of rubygem-* packages in our devel:languages:ruby:extensions Build Service repository compared with the corresponding gem versions on Gemcutter. Using this script and a great gem2rpm (more particularly gem2rpm-opensuse command which applies openSUSE template and is available from rubygem-gem2rpm package), I was able to update nearly a hundred of gems in just two hours. Rails rubygems have a specific packaging in openSUSE, so I left them out, but more than 90% of the rest didn’t need any changes in autogenerated spec file.

This brought me an idea. If only Gemcutter had an option to somehow send out notification that a new gem has been pushed, we could automate the process and have up-to-date rubygems in our devel:languages:ruby:extensions repository almost instantly. (We would still need to keep the list of “dirty” rubygems that need to be updated manually, though. For example, Rails packages I mentioned earlier, where we keep multiple versions, or others where we need to add a patch replacing /usr/local/bin/ruby with /usr/bin/ruby in scripts).

Few days later, Gemcutter gained RSS feed support, but only for the gems one is interested in. I didn’t find the option to have RSS feed for all gems. This could have helped in creating such mechanism, but that won’t be needed anymore because …

… yesterday Nick Quaranto of Gemcutter announced webhook support. I’m really excited, because that’s exactly what we need! When one registers a webhook, Gemcutter emits a POST request on a certain URL when a gem is pushed or updated. This request is a JSON document containing the info about gem. What we need is to create a mechanism that:

• receives notification via POST JSON request
• checks whether the package is not “dirty” → exit if it is (and probably send some email …)
• fetches the package from the Build Service or create a new one
• fetches the new gem, removes the old one
• runs gem2rpm-opensuse to create a spec file replacing the old one
• adds changelog entry
• pushes the updated package back into the Build Service

Last but not least: If Fedora and Mandriva had gem2rpm templates in a perfect shape too, Build Service could provide packaged gems also for their distributions.

So what do you think? Any volunteers for this? Right now, I’m off to fix some small bugs I found in gem2rpm while fiddling with it …

If you need to get the full URL of an image, just put the following code snippet into ApplicationHelper module in your app/helpers/application_helper.rb:

  def image_url(source)
    abs_path = image_path(source)
    unless abs_path =~ /^http/
      abs_path = "#{request.protocol}#{request.host_with_port}#{abs_path}"
    end
   abs_path
  end

I wonder why this function is not already a standard part of Rails.

(Idea by Rob Biedenharn)