[Bio-packaging] Guix rubygem builder

[David Thompson]

Hey Pjotr,

A few additional thoughts to add to my previous reply:

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

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

I misunderstood this the first time, and now I understand what you
mean. :)

The ruby-build-system doesn't specifically disallow downloading other
dependencies because it's not possible to do so from the build container
where only the loopback network device is available.

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

I've decided that we should try to report such bugs upstream and
temporarily disable the test phase until the problem is resolved.

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

So, right now I'm leaning towards just using the .gem archives from
rubygems.org.  I'm going to merge your rubygem-build-system with the
ruby-build-system and see if I can convert all of the existing Ruby
packages to it without serious loss of test suite coverage.  I'll ping
you when I have results.

In the event that we want to use a tarball instead of a gem archive, we
can easily handle that with a build system argument like #:build-gem?
that defaults to false, and an 'unpack' phase that DTRT with .gems *and*
tarballs.

If this works, the next step would be to write 'guix import rubygems' to
accelerate packaging.

How does that sound?  Thanks for bearing with me.

-- 
David Thompson
GPG Key: 0FF1D807