Re: [PATCH] Add yaggo.

["Thompson, David" <dthompson2@worcester.edu>]

On Wed, Jun 24, 2015 at 1:51 AM, Pjotr Prins <pjotr.public12@thebird.nl> wrote:
> On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
>> Actually, I lie, this patch only sort of works. The issue is that it
>> only works when a ruby package is also installed, GEM_PATH does not
>> get set as part of the ruby-build-system for yaggo. The lib/ files
>> are copied to what I gather is the correct place, but the env isn't
>> right.
>>
>> The same also appears to be true of other ruby packages e.g. ruby-hoe:
>> $ guix package -i ruby-hoe
>> ..
>> ben@u:~/git/guix$ guix package --search-paths
>> warning: failed to install locale: Invalid argument
>> export PATH="/home/ben/.guix-profile/bin:/home/ben/.guix-profile/sbin"
>> export PYTHONPATH="/home/ben/.guix-profile/lib/python3.4/site-packages"
>> export PKG_CONFIG_PATH="/home/ben/.guix-profile/lib/pkgconfig:/home/ben/.guix-profile/share/pkgconfig"
>> export GUILE_LOAD_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
>> export GUILE_LOAD_COMPILED_PATH="/home/ben/.guix-profile/share/guile/site/2.0"
>> export CPATH="/home/ben/.guix-profile/include"
>> export LIBRARY_PATH="/home/ben/.guix-profile/lib"
>> export ACLOCAL_PATH="/home/ben/.guix-profile/share/aclocal"
>>
>> i.e. no GEM_PATH entry, hence:
>
> That is correct. The Ruby support system is still in development.
>
> Adding the GEM_PATH is on the books as well as GEM_HOME and
> GEM_SPEC_CACHE to have the gem and rspec tools work also outside GNU
> Guix.

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.

> At the moment we are working on native gems (i.e. those that contain
> C code). I am also planning for a rubygem-build-system which would
> allow us to include gems with very simple package definitions, e.g.,
> rather then
>
>   (define-public ruby-i18n
>     (package
>       (name "ruby-i18n")
>       (version "0.6.11")
>       (source (origin
>                 (method url-fetch)
>                 (uri (string-append "https://github.com/svenfuchs/i18n/archive/v"
>                                     version ".tar.gz"))
>                 (file-name (string-append name "-" version ".tar.gz"))
>                 (sha256
>                  (base32
>                   "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
>       (build-system ruby-build-system)
>       (synopsis "Internationalization library for Ruby")
>       (...)
>
> we get
>
>   (define-public ruby-i18n
>     (package
>       (name "ruby-i18n")
>       (version "0.6.11")
>       (source (origin
>                 (method gem-fetch)
>                 (file-name (string-append name "-" version ".gem"))
>                 (sha256
>                  (base32
>                   "1fdhnhh1p5g8vibv44d770z8nq208zrms3m2nswdvr54072y1m6k"))))
>       (build-system rubygem-build-system)
>       (synopsis "Internationalization library for Ruby")
>       (...)
>
> 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?

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

Thanks,

- Dave