Re: [PATCH] Add yaggo.

[Thompson, David]

On Wed, Jun 24, 2015 at 3:23 PM, Pjotr Prins <address@hidden> wrote:
> On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
>> I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
>> search path that is part of our ruby packages, because native search
>> paths are relative to store items, which are immutable.  My feeling is
>> that if the user wants to use the 'gem' utility instead of using Guix
>> packages, they're going to have to set an environment variable or two
>> by themselves.
>
> It is just a convenience. I believe GNU Guix should allow extra
> package systems - like those of emacs. So point GEM_HOME to something
> that is not immutable.
>
>> > which would install directly from rubygems.org (including contained
>> > dependencies when missing in the existing environment).
>>
>> Are you saying that it would bundle the dependencies if there were no
>> Guix packages for them?
>
> Exactly.

This will work against our goals.  It will create a lot of duplicated
files which will eat up extra disk space and make it difficult to
apply security patches.  The  job of a distribution is to deduplicate,
not bundle.  Furthermore, it will cover up the lack of such packages
in Guix and discourage people from packaging them.  Instead, we could
make a 'guix import rubygems' program that generates all the necessary
package boilerplate for the requested package and for the missing
dependencies.

>> > This would greatly facilitate adding Ruby gems to guix.
>>
>> I must reiterate my concern about this approach to the wider
>> guix-devel audience.  From what I can see, the gem archives hosted on
>> rubygems.org are build artifacts and should probably be treated like
>> pre-built binaries.  They are not the complete, corresponding source
>> code.  Can anyone else weigh in here?  I understand the convenience of
>> using rubygems.org, but I really need some evidence that the archives
>> hosted there are complete, corresponding source code.
>
> Please see it as a migration path. There are tens of thousands of
> useful gems out there with complex dependencies. There is no way we
> are going to replace and test those overnight. Same for Python and
> Perl modules (and all those other languages with their own module
> system). I do favour pure Guix packages, also for gems, so we should
> aim for replacing the most important ones over time.

Ricardo's response earlier in the thread has given me some confidence
that the gem archives on rubygems.org do qualify as the corresponding
source code.  That said, we really cannot use pre-built software under
any circumstances, because it compromises the project's goals of
reproducibility and the ethics of free software.  Fortunately for us,
rubygems.org seems to be OK, so let's adjust ruby-build-system as
needed.  It should work just fine, but we need to make sure that we
can still unpack the gem archive and run the test suite successfully
before installing to the output directory in the store.

> Making it hard(er) to install gems from GNU Guix for normal users will
> only slow down adoption. Allow using rubygems for those gems that are
> not (yet) supported by us. When enough Ruby people move to using Guix
> for their development we may get rid of rubygems altogether. I would
> love that. I already got rid of rvm :)

I'm not advocating that we prevent users from using 'gem'.  Right now,
it is possible for users to 'gem install bundler' and build Ruby
applications as they typically would.  I have done so on my GuixSD
machine.  So, let's package things the right way and let people just
use 'bundler' if they want some other stuff.

> Nix experimented by converting all gems to Nix packages, that is
> another possibility. But I think they proved it is hard and now
> defunct (correct me if I am wrong).

We of course wouldn't just auto-generate *everything* and dump it in
the repo.  There's still the human work of inspecting licenses,
writing synopses and descriptions, adding unspecified dependencies
(happens a lot), etc.

- Dave