ilyakooo0/nixpkgs
1
0
Fork 0
mirror of https://github.com/ilyakooo0/nixpkgs.git synced 2024-12-29 06:45:54 +03:00
Code Issues Projects Releases Wiki Activity

Merge pull request #105200 from ryantm/update-ruby-doc

Browse Source 
doc: Ruby to CommonMark
This commit is contained in:
Ryan Mulligan 2020-11-28 07:34:45 -08:00 committed by GitHub
commit 3c40c276fa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 64 additions and 266 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/languages-frameworks/index.xml
View File

@ -27,7 +27,7 @@
<xi:include href="python.section.xml" /> <xi:include href="python.section.xml" />
<xi:include href="qt.xml" /> <xi:include href="qt.xml" />
<xi:include href="r.section.xml" /> <xi:include href="r.section.xml" />
<xi:include href="ruby.xml" /> <xi:include href="ruby.section.xml" />
<xi:include href="rust.section.xml" /> <xi:include href="rust.section.xml" />
<xi:include href="texlive.xml" /> <xi:include href="texlive.xml" />
<xi:include href="titanium.section.xml" /> <xi:include href="titanium.section.xml" />

221
doc/languages-frameworks/ruby.section.md
View File

@ -1,74 +1,38 @@
--- # Ruby {#sec-language-ruby}
title: Ruby
author: Michael Fellinger
date: 2019-05-23
---
# Ruby ## Using Ruby
## User Guide Several 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 2.6. It's also possible to refer to specific versions, e.g. `ruby_2_y`, `jruby`, or `mruby`.
### Using Ruby In 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).
#### Overview There 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.
Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_2_6.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
The attribute `ruby` refers to the default Ruby interpreter, which is currently
MRI 2.5. It's also possible to refer to specific versions, e.g. `ruby_2_6`, `jruby`, or `mruby`.
In the nixpkgs tree, Ruby packages can be found throughout, depending on what Since 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.
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).
There are two main approaches for using Ruby with gems. ### Temporary Ruby environment with `nix-shell`
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.
The interpreters have common attributes, namely `gems`, and `withPackages`. So Rather 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`.
you can refer to `ruby.gems.nokogiri`, or `ruby_2_5.gems.nokogiri` to get the
Nokogiri gem already compiled and ready to use.
Since not all gems have executables like `nokogiri`, it's usually more There 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.
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.
#### Temporary Ruby environment with `nix-shell` ```ShellSession
$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
Rather 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`.
There 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.
```shell
nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
``` ```
The other method, which is not recommended, is to create an environment and list The other method, which is not recommended, is to create an environment and list all the packages directly.
all the packages directly.
```shell ```ShellSession
nix-shell -p ruby.gems.nokogiri ruby.gems.pry $ nix-shell -p ruby.gems.nokogiri ruby.gems.pry
``` ```
Again, it's possible to launch the interpreter from the shell. The Ruby Again, 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.
interpreter has the attribute `gems` which contains all Ruby gems for that
specific interpreter.
##### Load environment from `.nix` expression #### Load Ruby environment from `.nix` expression
As explained in the Nix manual, `nix-shell` can also load an expression from a As explained in the Nix manual, `nix-shell` can also load an expression from a `.nix` file. Say we want to have Ruby 2.6, `nokogori`, and `pry`. Consider a `shell.nix` file with:
`.nix` file. Say we want to have Ruby 2.5, `nokogori`, and `pry`. Consider a
`shell.nix` file with:
```nix ```nix
with import <nixpkgs> {}; with import <nixpkgs> {};
@ -77,43 +41,33 @@ ruby.withPackages (ps: with ps; [ nokogiri pry ])
What's happening here? What's happening here?
1. We begin with importing the Nix Packages collections. `import <nixpkgs>` 1. 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.
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.
2. Then we create a Ruby environment with the `withPackages` function. 2. Then we create a Ruby environment with the `withPackages` function.
3. The `withPackages` function expects us to provide a function as an argument 3. 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.
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.
##### Execute command with `--run` #### Execute command with `--run`
A convenient flag for `nix-shell` is `--run`. It executes a command in the A convenient flag for `nix-shell` is `--run`. It executes a command in the `nix-shell`. We can e.g. directly open a `pry` REPL:
`nix-shell`. We can e.g. directly open a `pry` REPL:
```shell ```ShellSession
nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry" $ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry"
``` ```
Or immediately require `nokogiri` in pry: Or immediately require `nokogiri` in pry:
```shell ```ShellSession
nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri" $ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri"
``` ```
Or run a script using this environment: Or run a script using this environment:
```shell ```ShellSession
nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb" $ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb"
``` ```
##### Using `nix-shell` as shebang #### Using `nix-shell` as shebang
In fact, for the last case, there is a more convenient method. You can add a In 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.
[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.
```ruby ```ruby
#! /usr/bin/env nix-shell #! /usr/bin/env nix-shell
@ -126,35 +80,24 @@ body = RestClient.get('http://example.com').body
puts Nokogiri::HTML(body).at('h1').text puts Nokogiri::HTML(body).at('h1').text
``` ```
### Developing with Ruby ## Developing with Ruby
#### Using an existing Gemfile ### Using an existing Gemfile
In most cases, you'll already have a `Gemfile.lock` listing all your dependencies. In 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.
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.
So the steps from having just a `Gemfile` to a `gemset.nix` are: So the steps from having just a `Gemfile` to a `gemset.nix` are:
```shell ```ShellSession
bundle lock $ bundle lock
bundix $ bundix
``` ```
If you already have a `Gemfile.lock`, you can simply run `bundix` and it will If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.
work the same.
To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, To 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.
which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent
time of modification.
Once the `gemset.nix` is generated, it can be used in a Once the `gemset.nix` is generated, it can be used in a `bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
`bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
```nix ```nix
# ... # ...
@ -166,41 +109,26 @@ let
in mkShell { buildInputs = [ gems gems.wrappedRuby ]; } in mkShell { buildInputs = [ gems gems.wrappedRuby ]; }
``` ```
With this file in your directory, you can run `nix-shell` to build and use the gems. With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.
The important parts here are `bundlerEnv` and `wrappedRuby`.
The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that The `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.
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.
One common issue that you might have is that you have Ruby 2.6, but also One common issue that you might have is that you have Ruby 2.6, 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:
`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:
```nix ```nix
# ... # ...
mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; } mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
``` ```
### Gem-specific configurations and workarounds
#### Gem-specific configurations and workarounds In some cases, especially if the gem has native extensions, you might need to modify the way the gem is built.
In some cases, especially if the gem has native extensions, you might need to This is done via a common configuration file that includes all of the workarounds for each gem.
modify the way the gem is built.
This is done via a common configuration file that includes all of the This 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.
workarounds for each gem.
This file lives at `/pkgs/development/ruby-modules/gem-config/default.nix`, In the meanwhile, or if the modification is for a private gem, you can also add the configuration to only your own environment.
since it already contains a lot of entries, it should be pretty easy to add the
modifications you need for your needs.
In the meanwhile, or if the modification is for a private gem, you can also add
the configuration to only your own environment.
Two places that allow this modification are the `ruby` derivation, or `bundlerEnv`. Two places that allow this modification are the `ruby` derivation, or `bundlerEnv`.
@ -261,10 +189,9 @@ let
in pkgs.ruby.withPackages (ps: with ps; [ pg ]) in pkgs.ruby.withPackages (ps: with ps; [ pg ])
``` ```
Then we can get whichever postgresql version we desire and the `pg` gem will Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:
always reference it correctly:
```shell ```ShellSession
$ nix-shell --argstr pg_version 9_4 --run 'ruby -rpg -e "puts PG.library_version"' $ nix-shell --argstr pg_version 9_4 --run 'ruby -rpg -e "puts PG.library_version"'
90421 90421
@ -272,24 +199,15 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
100007 100007
``` ```
Of course for this use-case one could also use overlays since the configuration Of 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.
for `pg` depends on the `postgresql` alias, but for demonstration purposes this
has to suffice.
#### Adding a gem to the default gemset ### Adding a gem to the default gemset
Now that you know how to get a working Ruby environment with Nix, it's time to Now 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.
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.
All gems in the standard set are automatically generated from a single All 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 to each other.
`Gemfile`. The dependency resolution is done with `bundler` and makes it more
likely that all gems are compatible to each other.
In order to add a new gem to nixpkgs, you can put it into the In 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`.
`/pkgs/development/ruby-modules/with-packages/Gemfile` and run
`./maintainers/scripts/update-ruby-packages`.
To test that it works, you can then try using the gem with: To test that it works, you can then try using the gem with:
@ -297,16 +215,11 @@ To test that it works, you can then try using the gem with:
NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-your-gem ])" NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-your-gem ])"
``` ```
#### Packaging applications ### Packaging applications
A common task is to add a ruby executable to nixpkgs, popular examples would be A 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.
`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.
The absolute easiest way to do that is to write a The absolute easiest way to do that is to write a `Gemfile` along these lines:
`Gemfile` along these lines:
```ruby ```ruby
source 'https://rubygems.org' do source 'https://rubygems.org' do
@ -314,10 +227,7 @@ source 'https://rubygems.org' do
end end
``` ```
If you want to package a specific version, you can use the standard Gemfile If 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 simply running the `bundle lock` and `bundix` steps again.
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 simply running the `bundle lock` and
`bundix` steps again.
Now you can also also make a `default.nix` that looks like this: Now you can also also make a `default.nix` that looks like this:
@ -331,20 +241,15 @@ bundlerApp {
} }
``` ```
All that's left to do is to generate the corresponding `Gemfile.lock` and All 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.
`gemset.nix` as described above in the `Using an existing Gemfile` section.
##### Packaging executables that require wrapping #### Packaging executables that require wrapping
Sometimes your app will depend on other executables at runtime, and tries to Sometimes your app will depend on other executables at runtime, and tries to find it through the `PATH` environment variable.
find it through the `PATH` environment variable.
In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
gem in another script that prefixes the `PATH`.
Of course you could also make a custom `gemConfig` if you know exactly how to Of 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.
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.
Here's another example: Here's another example:

107
doc/languages-frameworks/ruby.xml
View File

@ -1,107 +0,0 @@
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="sec-language-ruby">
<title>Ruby</title>
<para>
There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.
</para>
<para>
For example, to package sensu, we did:
</para>
<screen>
<prompt>$ </prompt>cd pkgs/servers/monitoring
<prompt>$ </prompt>mkdir sensu
<prompt>$ </prompt>cd sensu
<prompt>$ </prompt>cat > Gemfile
source 'https://rubygems.org'
gem 'sensu'
<prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
<prompt>$ </prompt>cat > default.nix
{ lib, bundlerEnv, ruby }:
bundlerEnv rec {
name = "sensu-${version}";
version = (import gemset).sensu.version;
inherit ruby;
# expects Gemfile, Gemfile.lock and gemset.nix in the same directory
gemdir = ./.;
meta = with lib; {
description = "A monitoring framework that aims to be simple, malleable, and scalable";
homepage = "http://sensuapp.org/";
license = with licenses; mit;
maintainers = with maintainers; [ theuni ];
platforms = platforms.unix;
};
}
</screen>
<para>
Please check in the <filename>Gemfile</filename>, <filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily.
</para>
<para>
Updating Ruby packages can then be done like this:
</para>
<screen>
<prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
<prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
<prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
</screen>
<para>
For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
</para>
<programlisting>
<![CDATA[{ lib, bundlerApp }:
bundlerApp {
pname = "corundum";
gemdir = ./.;
exes = [ "corundum-skel" ];
meta = with lib; {
description = "Tool and libraries for maintaining Ruby gems.";
homepage = "https://github.com/nyarly/corundum";
license = licenses.mit;
maintainers = [ maintainers.nyarly ];
platforms = platforms.unix;
};
}]]>
</programlisting>
<para>
The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.
</para>
<para>
Resulting derivations for both builders also have two helpful attributes, <literal>env</literal> and <literal>wrappedRuby</literal>. The first one allows one to quickly drop into <command>nix-shell</command> with the specified environment present. E.g. <command>nix-shell -A sensu.env</command> would give you an environment with Ruby preset so it has all the libraries necessary for <literal>sensu</literal> in its paths. The second one can be used to make derivations from custom Ruby scripts which have <filename>Gemfile</filename>s with their dependencies specified. It is a derivation with <command>ruby</command> wrapped so it can find all the needed dependencies. For example, to make a derivation <literal>my-script</literal> for a <filename>my-script.rb</filename> (which should be placed in <filename>bin</filename>) you should run <command>bundix</command> as specified above and then use <literal>bundlerEnv</literal> like this:
</para>
<programlisting>
<![CDATA[let env = bundlerEnv {
name = "my-script-env";
inherit ruby;
gemfile = ./Gemfile;
lockfile = ./Gemfile.lock;
gemset = ./gemset.nix;
};
in stdenv.mkDerivation {
name = "my-script";
buildInputs = [ env.wrappedRuby ];
script = ./my-script.rb;
buildCommand = ''
install -D -m755 $script $out/bin/my-script
patchShebangs $out/bin/my-script
'';
}]]>
</programlisting>
</section>