Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Guix

dthompson.us

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Ruby on Guix

#41

Post by roller »

I imagine everything said in the article also applies to the Nix package manager[0]. One of its nice features is the Nix expression language (aka Nix) [1]. It has an elegant mixture of purity and pragmatism. I imagine guile scheme would have a lot more integration opportunities outside of just system/build/configuration management. It'd be interesting to see Guix expressions that actually mix other scheme libraries or concepts, rather than just taking Nix expressions and removing the syntax.

[0]: http://nixos.org/nix/ [1]: http://nixos.org/nix/manual/#chap-writing-nix-expressions

Re: Ruby on Guix

#42

Post by davexunit »

roller wrote: post #41

I imagine everything said in the article also applies to the Nix package manager[0]. One of its nice features is the Nix expression language (aka Nix) [1]. It has an elegant mixture of purity and pragmatism. I imagine guile scheme would have a lot more integration opportunities outside of just system/build/configuration management. It'd be interesting to see Guix expressions that actually mix other scheme libraries o…

>It'd be interesting to see Guix expressions that actually mix other scheme libraries or concepts, rather than just taking Nix expressions and removing the syntax.

We already do this. Our build scripts are written in Guile, not Bash like in Nix, and they take advantage of Guile's standard library which has things like a pattern matcher, an HTTP client and server, a POSIX interface, a foreign-function interface, an XML parser, etc. We use third-party libraries such as guile-json and guile-charting in some of our tools, as well.

Re: Ruby on Guix

#43

Post by rekado »

roller wrote: post #41

I imagine everything said in the article also applies to the Nix package manager[0]. One of its nice features is the Nix expression language (aka Nix) [1]. It has an elegant mixture of purity and pragmatism. I imagine guile scheme would have a lot more integration opportunities outside of just system/build/configuration management. It'd be interesting to see Guix expressions that actually mix other scheme libraries o…

I very much like how Guix is just a Guile Scheme library and can itself be integrated with other Scheme code. There is, for example, guix-web, a web interface to the package manager; there also is an Emacs interface using geiser.

Using Guile has turned out to be a great feature in itself and it is still fueling the development of new features that otherwise would be awkward to implement, such as the new "guix graph" command to visualise dependencies.

Re: Ruby on Guix

#44

Post by cstrahan »

zimbatm wrote: post #10
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…

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

https://github.com/NixOS/nixpkgs/pull/8612

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:

https://github.com/bundler/bundler/pull/3775

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.

Re: Ruby on Guix

#45

Post by zimbatm »

cstrahan wrote: post #44
zimbatm wrote: post #10

Earlier quoted context omitted.

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…

> 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: https://github.com/NixOS/nixpkgs/pull/8612 Unfortunately, while Bundler is generally a gr…

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 ?

Re: Ruby on Guix

#46

Post by rokgarbas »

1_player wrote: post #14

Can guix be used somewhat like virtualenv? I'm not sure I want to install guix on my main Archlinux box, as I don't want conflicts with the existing libraries and applications, but I would very much play with it if it were possible to do something like this: guix virtualenv myapp cd myapp guix activate guix install postgres # installs a local postgres installation available only on this "environment" guix environment…

nix has tools to convert gemfile into nix expressions http://lists.science.uu.nl/pipermail/nix-dev/2015-January/01...

Re: Ruby on Guix

#47

Post by rokgarbas »

transfire wrote: post #19

Some of these issues can be resolved using Ruby Install https://github.com/postmodern/ruby-install

i think guix/nix solution (can) goes beyond ruby platform and you can define dependencies on non ruby components: postresql, mysql, mongodb, ...

Re: Ruby on Guix

#48

Post by bro-stick »

davexunit wrote: post #15
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? That would be Guix. We use the same primitive utilities for package management and system configuration management. I'm typing this from a laptop running the GuixSD distro, and if a system upgrade were to break things, I can roll-back to a previous, working generation of the system at boot time and keep on going.

That make a ton of sense because the boundaries between packaging and cfg management are artificial.

Re: Ruby on Guix

#49

Post by bro-stick »

josteink wrote: post #8
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 :)

LOL. Emacs is RMS'es CLI to the world. It's fine. ;)

Re: Ruby on Guix

#50

Post by waxjar »

regularfry wrote: post #37
waxjar wrote: post #32

I like the approach of using gs (simple gemsets) [1] and dep (simple dependencies) [2]. I've been using this approach of handling dependencies for a while now. I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs",…

Instead of changing environment variables when $PWD changes, I went the other way: make it obvious when you're in a subshell by strapping $VIRTUAL_ENV onto $PS1. Again, simple shell scripts win[0][1]. I'm still interested in a cross-language approach, but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree. Unless Gemfile.lock is involved,…

I do something similar to this. My right prompt shows a small fork symbol when I'm in a sub-shell (based on $SHLVL). However, this does not help me much when I'm several levels deep, which is why eventually I started hooking in on changes to $PWD.
Post reply on HN