pyrox.dev
1# Ruby {#sec-language-ruby}
2
3## Using Ruby {#using-ruby}
4
5Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The attribute `ruby` refers to the default Ruby interpreter, which is currently MRI 3.3. It's also possible to refer to specific versions, e.g. `ruby_3_y`, `jruby`, or `mruby`.
6
7In the Nixpkgs tree, Ruby packages can be found throughout, depending on what they do, and are called from the main package set. Ruby gems, however are separate sets, and there's one default set for each interpreter (currently MRI only).
8
9There are two main approaches for using Ruby with gems. One is to use a specifically locked `Gemfile` for an application that has very strict dependencies. The other is to depend on the common gems, which we'll explain further down, and rely on them being updated regularly.
10
11The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_3_2.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
12
13Since not all gems have executables like `nokogiri`, it's usually more convenient to use the `withPackages` function like this: `ruby.withPackages (p: with p; [ nokogiri ])`. This will also make sure that the Ruby in your environment will be able to find the gem and it can be used in your Ruby code (for example via `ruby` or `irb` executables) via `require "nokogiri"` as usual.
14
15### Temporary Ruby environment with `nix-shell` {#temporary-ruby-environment-with-nix-shell}
16
17Rather than having a single Ruby environment shared by all Ruby development projects on a system, Nix allows you to create separate environments per project. `nix-shell` gives you the possibility to temporarily load another environment akin to a combined `chruby` or `rvm` and `bundle exec`.
18
19There are two methods for loading a shell with Ruby packages. The first and recommended method is to create an environment with `ruby.withPackages` and load that.
20
21```ShellSession
22$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
23```
24
25The other method, which is not recommended, is to create an environment and list all the packages directly.
26
27```ShellSession
28$ nix-shell -p ruby.gems.nokogiri ruby.gems.pry
29```
30
31Again, it's possible to launch the interpreter from the shell. The Ruby interpreter has the attribute `gems` which contains all Ruby gems for that specific interpreter.
32
33#### Load Ruby environment from `.nix` expression {#load-ruby-environment-from-.nix-expression}
34
35As explained [in the `nix-shell` section](https://nixos.org/manual/nix/stable/command-ref/nix-shell) of the Nix manual, `nix-shell` can also load an expression from a `.nix` file.
36Say we want to have Ruby, `nokogori`, and `pry`. Consider a `shell.nix` file with:
37
38```nix
39with import <nixpkgs> { };
40ruby.withPackages (
41 ps: with ps; [
42 nokogiri
43 pry
44 ]
45)
46```
47
48What's happening here?
49
501. We begin with importing the Nix Packages collections. `import <nixpkgs>` imports the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. These attributes form the main package set.
512. Then we create a Ruby environment with the `withPackages` function.
523. The `withPackages` function expects us to provide a function as an argument that takes the set of all ruby gems and returns a list of packages to include in the environment. Here, we select the packages `nokogiri` and `pry` from the package set.
53
54#### Execute command with `--run` {#execute-command-with---run}
55
56A convenient flag for `nix-shell` is `--run`. It executes a command in the `nix-shell`. We can e.g. directly open a `pry` REPL:
57
58```ShellSession
59$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry"
60```
61
62Or immediately require `nokogiri` in pry:
63
64```ShellSession
65$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri"
66```
67
68Or run a script using this environment:
69
70```ShellSession
71$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb"
72```
73
74#### Using `nix-shell` as shebang {#using-nix-shell-as-shebang}
75
76In fact, for the last case, there is a more convenient method. You can add a [shebang](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) to your script specifying which dependencies `nix-shell` needs. With the following shebang, you can just execute `./example.rb`, and it will run with all dependencies.
77
78```ruby
79#! /usr/bin/env nix-shell
80#! nix-shell -i ruby -p "ruby.withPackages (ps: with ps; [ nokogiri rest-client ])"
81
82require 'nokogiri'
83require 'rest-client'
84
85body = RestClient.get('http://example.com').body
86puts Nokogiri::HTML(body).at('h1').text
87```
88
89## Developing with Ruby {#developing-with-ruby}
90
91### Using an existing Gemfile {#using-an-existing-gemfile}
92
93In most cases, you'll already have a `Gemfile.lock` listing all your dependencies. This can be used to generate a `gemset.nix` which is used to fetch the gems and combine them into a single environment. The reason why you need to have a separate file for this, is that Nix requires you to have a checksum for each input to your build. Since the `Gemfile.lock` that `bundler` generates doesn't provide us with checksums, we have to first download each gem, calculate its SHA256, and store it in this separate file.
94
95So the steps from having just a `Gemfile` to a `gemset.nix` are:
96
97```ShellSession
98$ bundle lock
99$ bundix
100```
101
102If you already have a `Gemfile.lock`, you can run `bundix` and it will work the same.
103
104To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.
105
106Once the `gemset.nix` is generated, it can be used in a `bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
107
108```nix
109# ...
110let
111 gems = bundlerEnv {
112 name = "gems-for-some-project";
113 gemdir = ./.;
114 };
115in
116mkShell {
117 packages = [
118 gems
119 gems.wrappedRuby
120 ];
121}
122```
123
124With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.
125
126The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
127
128One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
129
130```nix
131# ...
132mkShell {
133 buildInputs = [
134 gems
135 (lowPrio gems.wrappedRuby)
136 ];
137}
138```
139
140Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:
141
142```nix
143{
144 gems = bundlerEnv {
145 name = "gems-for-some-project";
146 gemdir = ./.;
147 extraConfigPaths = [ "${./.}/.ruby-version" ];
148 };
149}
150```
151
152### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}
153
154In some cases, especially if the gem has native extensions, you might need to modify the way the gem is built.
155
156This is done via a common configuration file that includes all of the workarounds for each gem.
157
158This file lives at `/pkgs/development/ruby-modules/gem-config/default.nix`, since it already contains a lot of entries, it should be pretty easy to add the modifications you need for your needs.
159
160In the meanwhile, or if the modification is for a private gem, you can also add the configuration to only your own environment.
161
162Two places that allow this modification are the `ruby` derivation, or `bundlerEnv`.
163
164Here's the `ruby` one:
165
166```nix
167{
168 pg_version ? "10",
169 pkgs ? import <nixpkgs> { },
170}:
171let
172 myRuby = pkgs.ruby.override {
173 defaultGemConfig = pkgs.defaultGemConfig // {
174 pg = attrs: {
175 buildFlags = [
176 "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config"
177 ];
178 };
179 };
180 };
181in
182myRuby.withPackages (ps: with ps; [ pg ])
183```
184
185And an example with `bundlerEnv`:
186
187```nix
188{
189 pg_version ? "10",
190 pkgs ? import <nixpkgs> { },
191}:
192let
193 gems = pkgs.bundlerEnv {
194 name = "gems-for-some-project";
195 gemdir = ./.;
196 gemConfig = pkgs.defaultGemConfig // {
197 pg = attrs: {
198 buildFlags = [
199 "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config"
200 ];
201 };
202 };
203 };
204in
205mkShell {
206 buildInputs = [
207 gems
208 gems.wrappedRuby
209 ];
210}
211```
212
213And finally via overlays:
214
215```nix
216{
217 pg_version ? "10",
218}:
219let
220 pkgs = import <nixpkgs> {
221 overlays = [
222 (self: super: {
223 defaultGemConfig = super.defaultGemConfig // {
224 pg = attrs: {
225 buildFlags = [
226 "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config"
227 ];
228 };
229 };
230 })
231 ];
232 };
233in
234pkgs.ruby.withPackages (ps: with ps; [ pg ])
235```
236
237Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:
238
239```ShellSession
240$ nix-shell --argstr pg_version 9_4 --run 'ruby -rpg -e "puts PG.library_version"'
24190421
242
243$ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
244100007
245```
246
247Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
248
249### Platform-specific gems {#ruby-platform-specif-gems}
250
251Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).
252Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:
253- globally (will be set in `~/.config/.bundle/config`):
254```shell
255$ bundle config set force_ruby_platform true
256```
257- locally (will be set in `<project-root>/.bundle/config`):
258```shell
259$ bundle config set --local force_ruby_platform true
260```
261
262### Adding a gem to the default gemset {#adding-a-gem-to-the-default-gemset}
263
264Now that you know how to get a working Ruby environment with Nix, it's time to go forward and start actually developing with Ruby. We will first have a look at how Ruby gems are packaged on Nix. Then, we will look at how you can use development mode with your code.
265
266All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible with each other.
267
268In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
269
270To test that it works, you can then try using the gem with:
271
272```shell
273NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-your-gem ])"
274```
275
276### Packaging applications {#packaging-applications}
277
278A common task is to add a Ruby executable to Nixpkgs; popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables. Otherwise, the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
279
280The absolute easiest way to do that is to write a `Gemfile` along these lines:
281
282```ruby
283source 'https://rubygems.org' do
284 gem 'mdl'
285end
286```
287
288If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by running the `bundle lock` and `bundix` steps again.
289
290Now you can also make a `default.nix` that looks like this:
291
292```nix
293{ bundlerApp }:
294
295bundlerApp {
296 pname = "mdl";
297 gemdir = ./.;
298 exes = [ "mdl" ];
299}
300```
301
302All that's left to do is to generate the corresponding `Gemfile.lock` and `gemset.nix` as described above in the `Using an existing Gemfile` section.
303
304#### Packaging executables that require wrapping {#packaging-executables-that-require-wrapping}
305
306Sometimes your app will depend on other executables at runtime and try to find them through the `PATH` environment variable.
307
308In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
309
310Of course you could also make a custom `gemConfig` if you know exactly how to patch it, but it's usually much easier to maintain with a simple wrapper so the patch doesn't have to be adjusted for each version.
311
312Here's another example:
313
314```nix
315{
316 lib,
317 bundlerApp,
318 makeWrapper,
319 git,
320 gnutar,
321 gzip,
322}:
323
324bundlerApp {
325 pname = "r10k";
326 gemdir = ./.;
327 exes = [ "r10k" ];
328
329 nativeBuildInputs = [ makeWrapper ];
330
331 postBuild = ''
332 wrapProgram $out/bin/r10k --prefix PATH : ${
333 lib.makeBinPath [
334 git
335 gnutar
336 gzip
337 ]
338 }
339 '';
340}
341```