On Sun, Feb 21, 2016 at 12:16:58PM +0100, Ricardo Wurmus wrote: > > So any Ruby interpreter 2.2.x version will share the same gems. It is not > > necessarily a problem because the Ruby world is built around this > > assumption. But when I look at developer support and reproducibility I > > don't like it much. You can have software running with different Ruby > > interpreters under the hood - and you won't know it. > > Do they really reference different variants of Ruby in the background?
Potentially: when you have a gem already installed and you update Ruby to a newer version, you can run the old gem against the newer Ruby provided it looks in the profile path for modules. > The ruby-build-system adds the “ruby” package only to the build inputs. > I don’t have different “ruby-*” packages in my store right now (after > “guix gc”), so I cannot verify this myself. I would be interested to > know if references to the “ruby” package are actually retained when > building, say, “ruby-nokogiri”. Ruby is an input in the build system, right? After that... > I haven’t thought enough about this to have an opinion about this. > Generally, though, I dislike to use environment variables to point the > interpreter to a prefix where all libraries can be found. I think that > it’s up to the libraries themselves to find their dependencies (like > it’s done with RUNPATH). You are right. The same holds for Guile, python, perl, R and Ruby at this point. I think it would be OK to have a profile for every Ruby with libs. The main problem here is that ruby interpreters can get mixed in with existing (installed) modules. I think Dave has pointed this out in the past. Pj.
