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.
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.
> 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.
I'm glad to hear that the infrastructure is working for you. There are, admittedly, some kinks on master, though I have a PR to make things much, much more robust:
Unfortunately, while Bundler is generally a great, useful piece of software, there are aspects of its design that make it very difficult - borderline antithetical - to cooperate with packaging; if you look at the commit message in the above PR, you can see a thorough description of the challenges.
I have an open PR for Bundler to try to make things a bit more amenable, and recently got the thumbs up with respect to the general idea:
Unfortunately, most Ruby deployments are quite imperative in nature - just push to a git repository, bundle install, and then bundle exec (that's leaving out all of the subtle prereqs: `apt-get install ...`, etc), as with Capistrano. There doesn't appear to be as much of a culture around packaging (yet), and so there hasn't been a demand for the tools to meet those needs.
I hope that we can push through those problems and make it trivial for people to enjoy the ease/dependability/resiliency of package management, as many people have no idea what they're missing out on.
Nice ! That should solve the issue where all gems are re-installed whenever the Gemfile.lock is changed.
I agree that bundler is mainly focusing on the user interactions and is good at that but never look inside. I'm not even sure if the dependency resolution mechanism can be used as a library.
In my opinion bundler should only be used as a dependency-resolution manager. Once gems are installed then they should use good-ol' $LOAD_PATH. Unfortunately there are the git gems and also rails which insists on using bundler.
EDIT: got any thought on adding system dependencies per gem ?
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.