[Bio-packaging] Guix rubygem builder

[Pjotr Prins]

Hi Dave,

Now we have the difficult nokogiri gem packaged I have added a
'native' rubygem builder. See

  https://github.com/pjotrp/guix/blob/rubygems/guix/build/rubygem-build-system.scm

so now we can simply install rubygems with

(define-public ruby-log4r
  (package
    (name "ruby-log4r")
    (version "1.1.10")
    (source (origin
              (method url-fetch)
              (uri (string-append
                    "https://rubygems.org/downloads/log4r-" version ".gem"))
              (sha256
               (base32
                "0ri90q0frfmigkirqv5ihyrj59xm8pq5zcmf156cbdv4r4l2jicv"))))
    (build-system rubygem-build-system)   ;; <<<<===== here!
    (synopsis "A flexible logging library for Ruby")
    (description "Ruby Log4r features a hierarchical logging system of
any number of levels, custom level names, logger inheritance, multiple
output destinations per log event, execution tracing, custom
formatting, thread safetyness, XML and YAML configuration, and more.")
    (home-page "http://log4r.rubyforge.org/")
    (license license:expat)))

Because rubygems are usually 'prepackaged' it will often be simpler to
install these - rather than looking for the tar-ball or the checkout
of a git repo and making the command work.

Notice this rubygem-builder does not allow pulling in dependencies.
That should also go into the existing ruby-build-system!

For log4r I found (indeed) that the Rakefile is missing, so tests can
not be run for this gem.

Even so, I think we would be best served with a mixed packaging system
for Ruby modules. The existing one is great and should also allow for
git checkouts - that would help greatly when tar-ball releases are missing.

The gem download we can merge with the existing one (if the source is
a .gem we know what to do). I think we should allow for .gem based
packages as an *easy* if slightly unclean option. Convenience does
matter and since rubygems are deployed all over the place with the gem
command we can assume they normally work.

I do agree that important gems should be constructed from tar/git,
rather than a native gem.

Does this make sense to you? We can be purist on tar/git and leave out
downloadable gems, but that would limit Ruby support since it will
take longer to package gems. I (for one) will certainly start a
separate repository for gems if Guix won't allow for those. Ultimately
I am lazy ;)

Pj.