Re: using guix for ruby development

[Divan Santana]

Marius Bakke <address@hidden> writes:

> Divan Santana <address@hidden> writes:
>
>> Divan Santana <address@hidden> writes:
>>
>>> Hi all,
>>>
>>> So I'm *trying* to use guix on Parabola Linux to provide the rubies and
>>> replace some other functionality of like chruby for instance.
>>>
>>> I'm a bit of a noob with guix and even ruby, so it's a bit of a
>>> challenge.
>>>
>>> I've read through these nice notes[1] by Pjotr. The answers I'm looking
>>> for, may well be in there but I might have missed it.
>>>
>>>   [1]:
>>>     - https://gitlab.com/pjotrp/guix-notes/blob/master/RUBY.org
>>>     - https://gitlab.com/pjotrp/guix-notes/blob/master/RUBYGEMS-Nokogiri.org
>>>
>>> I've also used the linked in script[2] which helps.
>>>
>>> [2]: https://gitlab.com/pjotrp/guix-notes/blob/master/scripts/ruby-guix-env
>>>
>>> Anyway the issue:
>>>
>>>   $ gem env
>>>   RubyGems Environment:
>>>     - RUBYGEMS VERSION: 2.6.14
>>>     - RUBY VERSION: 2.4.3 (2017-12-14 patchlevel 205) [x86_64-linux]
>>>     - INSTALLATION DIRECTORY: 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0
>>>     - USER INSTALLATION DIRECTORY: /home/admin/.gem/ruby/2.4.0
>>>     - RUBY EXECUTABLE: 
>>> /gnu/store/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/bin/ruby
>>>     - EXECUTABLE DIRECTORY: 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/bin
>>>     - SPEC CACHE DIRECTORY: 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/specs
>>>     - SYSTEM CONFIGURATION DIRECTORY: 
>>> /gnu/store/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/etc
>>>     - RUBYGEMS PLATFORMS:
>>>       - ruby
>>>       - x86_64-linux
>>>     - GEM PATHS:
>>>        - /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0
>>>        - /home/admin/.guix-profile/lib/ruby/vendor_ruby
>>>        - /home/admin/.guix-profile/lib/ruby/gems/2.4.0/
>>>     - GEM CONFIGURATION:
>>>        - :update_sources => true
>>>        - :verbose => true
>>>        - :backtrace => false
>>>        - :bulk_threshold => 1000
>>>        - "gem" => "--no-rdoc"
>>>     - REMOTE SOURCES:
>>>        - https://rubygems.org/
>>>     - SHELL PATH:
>>>        - 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/bin
>>>        - /home/admin/src/ds-config/guile/scripts
>>>        - /home/admin/src/ds-config/bin
>>>        - /home/admin/.node_modules/node_modules/.bin
>>>        - /home/admin/.guix-profile/bin
>>>        - /home/admin/src/ds-config/guile/scripts
>>>        - /home/admin/src/ds-config/bin
>>>        - /home/admin/.node_modules/node_modules/.bin
>>>        - /home/admin/.guix-profile/bin
>>>        - /usr/local/sbin
>>>        - /usr/local/bin
>>>        - /usr/bin
>>>        - /usr/lib/jvm/default/bin
>>>        - /usr/bin/site_perl
>>>        - /usr/bin/vendor_perl
>>>        - /usr/bin/core_perl
>>>
>>> So I'm in a ruby project. I type `bundle install` to install the gems.
>>>
>>> It goes and fetches the missing gems and installs them in 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/
>>>
>>> That's great. I fire up the project[3] with:
>>>
>>>   [3]: https://gitlab.com/gitlab-com/gitlab-docs (using an older commit
>>>   because ruby25 is not yet in guix repos.
>>>
>>>   $ bundle exec nanoc live
>>>
>>>   Captain! We’ve been hit!
>>>
>>>   LoadError: liblzma.so.5: cannot open shared object file: No such file or 
>>> directory - 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/nokogiri-1.7.2/lib/nokogiri/nokogiri.so
>>>
>>>   $ ldd 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/nokogiri-1.7.2/lib/nokogiri/nokogiri.so
>>>           linux-vdso.so.1 (0x00007ffff6b10000)
>>>           libm.so.6 => /usr/lib/libm.so.6 (0x00007f469080f000)
>>>           libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f469060b000)
>>>           liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007f46903e5000)
>>>           libz.so.1 => /usr/lib/libz.so.1 (0x00007f46901ce000)
>>>           libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f468ffb0000)
>>>           libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f468fd78000)
>>>           libc.so.6 => /usr/lib/libc.so.6 (0x00007f468f9c1000)
>>>           /usr/lib64/ld-linux-x86-64.so.2 (0x00007f4690f97000)
>>>
>>> Guessing the reason is because it seems to compile against the OS system
>>> and not the "guix system". And that could cause problems?
>>>
>>> Other gems also are like this.
>>>
>>>   $ ldd 
>>> /home/admin/.gem/sx7ih0vgp7q8zj7k58xjvnp3yghig0ll-ruby-2.4.3/2.4.0/gems/ffi-1.9.18/lib/ffi_c.so
>>>           linux-vdso.so.1 (0x00007ffd1bdf1000)
>>>           libffi.so.6 => /usr/lib/libffi.so.6 (0x00007f6af531e000)
>>>           libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6af5100000)
>>>           libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f6af4efc000)
>>>           libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f6af4cc4000)
>>>           libm.so.6 => /usr/lib/libm.so.6 (0x00007f6af4978000)
>>>           libc.so.6 => /usr/lib/libc.so.6 (0x00007f6af45c1000)
>>>           /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6af574c000)
>>>
>>> I could install ruby-nokogiri via guix but that provides 1.8 and I need
>>> 1.7. :(
>>>
>>> Is there a simple way of getting these gems installed to use guix system
>>> libs so things don't break?
>>
>> So for this particular project I managed to get it working via changing
>> the Gemfile to up the version on nokogiri to 1.8 so I can use the
>> nokogiri from guix. Did the same with ffi which had similar issue.
>>
>> That's not ideal as one may need a diff version or the gem may not be
>> packaged yet.
>>
>> Any thoughts?
>
> Mixing Guix packages with other package managers can be difficult.  In
> this situation I would write a "Guixfile" and use that instead of
> Bundler.
>
> (use-modules (guix build-system ruby)
>            ((guix licenses) #:prefix license:)
>            (guix download)
>            (guix packages)
>            (gnu packages ruby))
>
> (define-public ruby-nokogiri-1.7
>   (package
>     (inherit ruby-nokogiri)
>     (version "1.7.0")
>     (source (origin
>             (method url-fetch)
>             (uri (rubygems-uri "nokogiri" version))
>             (sha256
>              (base32
>               "1qx2adp6gdnaipvv0nshiq2hgnra44c8j5vkjjfm73sr9wbdmbk3"))))))
>
> (define-public gitlab-docs
>   (package
>     (name "gitlab-docs")
>     (version "master")
>     (source (dirname (current-filename)))
>     (build-system ruby-build-system)
>     (propagated-inputs
>      `(("ruby-nokogiri" ,ruby-nokogiri-1.7)
>        ("ruby-redcarpet" ,ruby-redcarpet)))
>     (home-page "https://gitlab.com/gitlab-com/gitlab-docs";)
>     (synopsis "GitLab documentation")
>     (description "Documentation for the GitLab git server")
>     (license license:expat)))
>
> gitlab-docs
>
> And then start the environment with `guix environment -l Guixfile.scm`.
>
> I see the Gemfile requires some gems that are not available in Guix yet,
> so I would attempt to write package definitions for those as well.
>
> Hope this helps!

Thanks for this reply Marius.

Ideally one would do it this way and submit the packages applicable
back. When I get more familiar with things will do this.

For now I'm going to go with Christopher's method using direnv as that
is a quick win for now.
--
Divan