Ruby on Guix

#1

Post by rekado » Mon, Aug 31, 2015, 5:59 AM UTC

Re: Ruby on Guix

#2

Post by buren » Mon, Aug 31, 2015, 9:03 AM UTC

Looks pretty cool, though it is a pretty daunting task to convince all gem developers to test/make their gems compatible.

Perhaps this could make http://devblog.avdi.org/2015/08/11/what-its-like-to-come-bac... easier ;)

Re: Ruby on Guix

#3

Post by jfaucett » Mon, Aug 31, 2015, 9:51 AM UTC

I completely see the benefits of using guix, transactional package management seems at the very least an interesting alternative to docker in some scenarios, and could be very interesting from a tool automation perspective.

I don't want to sound negative, but I think the biggest problem with getting me or other ruby developers to package our gems to guix would be the following. The bundler/rbenv system I've been using for years is pretty darn good, personally I haven't had problems with it. I've used it in massive and small projects, and admittedly the only inconvenience is having to manually or through orchestration install the dependencies of certain gems, of which there are also only a few (mysql2 with libmysqlclient-dev and his nokogiri mention are probably the most notable). He does point this out but if you're using docker or some automation tool this is a pretty minor point.

Also I already ensure my gems run their tests on mri, jruby, rubinius, etc. and this seems like extra work for little benefit, especially when most in house deployment scenarios are running with docker or chef/puppet on top of the classic rbenv/rvm and bundler setup. My biggest question is after upgrading a gem version how easy is it for me to push the new version of the package to guix?

So essentially, I wish this article had more arguments to show why guix will better the life of ruby devs.

Re: Ruby on Guix

#4

Post by davidroetzel » Mon, Aug 31, 2015, 10:04 AM UTC

> I'm not sure how you feel, dear reader, but my Ruby environments feel like one giant, brittle hack

Of course things are not perfect (and guix may have a few cool ideas), but I think we should keep in mind that both rvm and bundler have been huge improvements.

The hacks people needed to come up with before rvm and bundler existed were an order of a magnitude more brittle.

Re: Ruby on Guix

#5

Post by bro-stick » Mon, Aug 31, 2015, 10:05 AM UTC

Notice the striking similarities of package management definition files and configuration management, where the latter does more related to state, coordination, attributes and templating files. Packages are just more generic containers of resources and metadata, configuration management makes those resources concrete on specific systems and applies tweaks to converge on the desired catalog state.

Btw, has anyone written a usable Guile-based cfg mgmt tool yet?

Re: Ruby on Guix

#6

Post by rekado » Mon, Aug 31, 2015, 10:15 AM UTC

bro-stick wrote: post #5

Notice the striking similarities of package management definition files and configuration management, where the latter does more related to state, coordination, attributes and templating files. Packages are just more generic containers of resources and metadata, configuration management makes those resources concrete on specific systems and applies tweaks to converge on the desired catalog state. Btw, has anyone writ…

Configuration management is slowly coming to Guix. Guix is the foundation of the Guix System Distribution, which is a system instantiated from a declarative system configuration file /etc/config.scm. There is work under way to extend this to managing multiple machines.

Re: Ruby on Guix

#7

Post by frontsideair » Mon, Aug 31, 2015, 10:15 AM UTC

I'm starting to think that I should go back to GoboLinux from Ubuntu.

Re: Ruby on Guix

#8

Post by josteink » Mon, Aug 31, 2015, 10:31 AM UTC

bro-stick wrote: post #5

Notice the striking similarities of package management definition files and configuration management, where the latter does more related to state, coordination, attributes and templating files. Packages are just more generic containers of resources and metadata, configuration management makes those resources concrete on specific systems and applies tweaks to converge on the desired catalog state. Btw, has anyone writ…

> Btw, has anyone written a usable Guile-based cfg mgmt tool yet?

When it comes, I'm certain it will come to Emacs first :)

Re: Ruby on Guix

#9

Post by ownedthx » Mon, Aug 31, 2015, 10:51 AM UTC

As someone who deploys Ruby software to our servers, I've come up with a formula that's served us well.

We take all gems associated with the app (like a Rails app, but we do it with others), and stuff them along with the code into a package created by fpm.

In other words, the packages are completely self-contained; no gems are used from the environment.

The key to this is the --path option to bundle install, i.e.:

bundle install --path vendor/bundle

This command makes sure all my gems are in a sub directory of my project called vendor/bundle. When creating the debian package using fpm which includes all the source code, vendor/bundle also comes along with the package.

After installing the app on our Linux servers, 'bundle exec rails server' uses the gems from vendor/bundle.

This approach does require that I create the debian package on a machine that closely mirrors the deployed servers, so that compiled gems make any sense.

Most all the issues described in the article have not been problems because of this approach. I used to use rvm as part of my build process; it was very brittle. I'm completely happy now; just wanted to share in case that helps someone else.

Re: Ruby on Guix

#10

Post by zimbatm » Mon, Aug 31, 2015, 11:39 AM UTC

jfaucett wrote: post #3

I completely see the benefits of using guix, transactional package management seems at the very least an interesting alternative to docker in some scenarios, and could be very interesting from a tool automation perspective. I don't want to sound negative, but I think the biggest problem with getting me or other ruby developers to package our gems to guix would be the following. The bundler/rbenv system I've been usin…

I don't know if it's the same with Guix but in NixOS it's just a matter of running `bundix` and all the Gemfile.lock dependencies are converted to a nix expression. Gem developers can keep developing as usual.

Maybe the only restriction is to make sure the gem has configurable paths if it tries to access system files.

I'm experimenting with it at the moment and converted my blog to be managed by nix on OSX. It's not a walk in the park but it's working. Clone the repo ( https://github.com/zimbatm/zimbatm.com ) and type `nix-shell` (needs to be installed first) and you should get all the blog dependencies available in your environment.