[Bio-packaging] Guix rubygem builder

[David Thompson]

Pjotr Prins <pjotr.public66 at thebird.nl> writes:

> Hi Dave,

Hey Pjotr.  I'm back from vacation.

> 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!

It's not the job of a build system to pull in dependencies.  They need
to be specified explicitly in the package recipe.  'guix import
rubygems' could do this, however, much like 'guix import pypi' now does.

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

This is the kind of stuff I'm really concerned about with using what's
on rubygems.org.

> 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.

I'd like to unify them into a single build system.  Maintaining both is
too much, IMO.

> 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 ;)

It all comes down to the quality of what's on rubygems.org.  It seems to
me so far that the quality is quite low, what with missing Rakefiles and
such, which lead to think that *no one* but us will be attempting to run
the test suites on these things.

Thanks for your effort.  We'll figure out how to unify things going
forward.

-- 
David Thompson
GPG Key: 0FF1D807