Using Nix: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Missing an --attr flag on the final example)
(Rewrite with focus on quickstart, new nix command, per-project usage, and tooling infrastructures)
Line 1: Line 1:
{{Draft}}
{{Draft}}


[https://nixos.org/nix/ Nix] is a package manager system that allows users to manage their own persistent software environment.  At the moment it is only available on graham.
= Overview =


* Users can build, install, upgrade, downgrade, and remove packages from their environment without root privileges and without affecting other users.
[https://nixos.org/nix/ Nix] is a package manager system that allows users to manage their own persistent software environments. At the moment it is only available on SHARCNET systems (i.e., graham and legacy). If you would like this to change, help motivate an expansion by letting us known (it requires some coordination, but isn't too difficult to do).
* Operations either succeed and create a new environment or fail leaving the previous environment in place (operations are atomic).
* Previous environments can be switched back to at any point.
* Users can add their own packages and share them with other users.


The default Nix package set includes a huge selection (over 10,000) of recent versions of many packages.
* Supports one-off, per-project, and per-user usage of packages
* Packages can be built, installed, upgraded, downgraded, and removed as a user
* Operations either succeed or fail leaving everything intact (operations are atomic).
* Extremely each to add and share packages


'''NOTE:''' The message <code>failed to lock thread to CPU XX</code> is a harmless warning that can be ignored.
'''NOTE:''' The message <code>failed to lock thread to CPU XX</code> is a harmless warning that can be ignored.
Line 14: Line 14:
== Enabling and disabling the Nix environment ==
== Enabling and disabling the Nix environment ==


The user's current Nix environment is enabled by loading the nix module. This creates some ''.nix*'' files and sets some environment variables.
The user’s current Nix environment is enabled by loading the nix module. This creates some ’‘.nix*’’ files and sets some environment variables.


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[name@cluster:~]$ module load nix</source>
|module load nix
It is disabled by unloading the nix module. This unsets the environment variables but leaves the ’‘.nix*’’ files alone.
}}


It is disabled by unloading the nix module. This unsets the environment variables but leaves the ''.nix*'' files alone.
<source lang="bash">[name@cluster:~]$ module unload nix</source>
== Completely resetting the Nix environment ==


{{Commands|prompt=[name@cluster:~]
Most operations can be undone with the <code>--rollback</code> option (i.e., <code>nix-env --rollback</code> or <code>nix-channel --rollback</code>). Sometimes it is useful to entirely reset nix though. This is done by unloading the module, erasing all user related nix files, and then reloading the module file.
|module unload nix
}}


== Completely reseting the Nix environment ==
<source lang="bash">[name@cluster:~]$ module unload nix
[name@cluster:~]$ rm -fr ~/.nix-profile ~/.nix-defexpr ~/.nix-channels ~/.config/nixpkgs
[name@cluster:~]$ rm -fr /nix/var/nix/profiles/per-user/$USER /nix/var/nix/gcroots/per-user/$USER
[name@cluster:~]$ module load nix</source>
= Basic package usage =


Most operations can be undone with the <code>--rollback</code> option (i.e.,  <code>nix-env --rollback</code> or  <code>nix-channel --rollback</code>). Sometimes it is useful to entirely reset nix though. This is done by unloading the module, erasing all user related nix files, and then reloading the module file.
The <code>nix search</code> command can be used to locate available packages


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[user@cluster:~]$ nix search git
|module unload nix
...
|rm -fr ~/.nix-profile ~/.nix-defexpr ~/.nix-channels ~/.config/nixpkgs
* nixpkgs.git (git-minimal-2.19.3)
|rm -fr /nix/var/nix/profiles/per-user/$USER /nix/var/nix/gcroots/per-user/$USER
  Distributed version control system
|module load nix
...</source>
}}
Pro tips include


= Installing and removing packages =
* you need to specify <code>-u</code> after upgrading your package set (this will take awhile)
* the search string is actually a regular expression and multiple ones are ANDed together


The <code>nix-env</code> command is used to setup your Nix environment.
Often we want to use a package in one of three ways: a one-time command Individual packages can be access in Nix in a variety of ways


== What do I have installed and what can I install ==
== One offs ==


Lets first see what we currently have installed.
If you just want to use a package once, the easiest was is to use the <code>nix run</code> command. This command will start a shell in which <code>PATH</code> has been extended to include the specified package


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[user@cluster:~]$ nix run nixpkg.git
|nix-env --query
[user@cluster:~]$ git
}}
[user@cluster:~]$ exit</source>
Note that this does not protect the package from being garbage collected overnight (e.g., the package is only guaranteed to be around temporarily for your use until sometime in the wee-morning hours). Pro tips include


Now let's see what is available. We request the attribute paths (unambiguous way of specifying a package) and the descriptions too (cursor to the right to see them). This takes a bit of time as it visits a lot of small files. Especially over NFS it can be a good idea to pipe it to a file and then grep that in the future.
* you can specify more than one package in the same <code>nix run</code> command
* you can specify a command instead of a shell with <code>-c &lt;cmd&gt; &lt;args&gt; ...</code>


{{Commands|prompt=[name@cluster:~]
== Per-project ==
|nix-env --query --available --attr-path --description
}}


== Installing packages ==
If you want to use a program for a specific project, the easiest way is with the <code>nix build</code> command. This command will create a symbolic link (by default named <code>result</code>) from which you can access the programs <code>bin</code> directory to run it.


Let's say that we need a newer version of git than provided by default. First lets check what our OS comes with.
<source lang="bash">[user@cluster:~]$ nix build nixpkgs.git
[user@cluster:~]$ ./result/bin/git</source>
Note that (currently) the package will only be protected from overnight garbage collection if you output the symlink into your <code>home</code> directory and do not rename or move it. Pro tips include


{{Commands|prompt=[name@cluster:~]
* you can specify the output symlink name with the <code>-o &lt;name&gt;</code> option
|git --version
* add the <code>bin</code> directory to your <code>PATH</code> to not have to type it in every time
|which git
}}


Let's tell Nix to install its version in our environment.
== Per-user ==


{{Commands|prompt=[name@cluster:~]
Loading the <code>nix</code> module adds the per-user common <code>~/.nix-profile/bin</code> directory to your <code>PATH</code>. You can add and remove packages from this directory with the <code>nix-env</code> command
|nix-env --install --attr nixpkgs.git
|nix-env --query
}}


Let's checkout what we have now (it may be necessary to tell bash to to forget remembered executable locations with <code>hash -r</code> so it notices the new one).
<source lang="bash">[user@cluster:~]$ nix-env --install --attr nixpkgs.git
[user@cluster:~]$ nix-env --query
git-minimal-2.19.3</source>
<source lang="bash">[user@cluster:~]$ nix-env --uninstall git-minimal
uninstalling 'git-minimal-2.19.3'
[user@cluster:~]$ nix-env --query</source>
Each command actually creates a new version, so all prior versions remain and can be used


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[user@cluster:~]$ nix-env --list-generations
|git --version
  1  2020-07-29 13:10:03
|which git
  2  2020-07-29 13:11:52  (current)
}}
[user@cluster:~]$ nix-env --switch-generation 1
[user@cluster:~]$ nix-env --query
git-minimal-2.19.3
[user@cluster:~]$ nix-env --switch-generation 2
[user@cluster:~]$ nix-env --query</source>
Pro tips include


== Removing packages ==
* <code>nix-env --rollback</code> moves up one generation
* <code>nix-env --delete-generations &lt;time&gt;</code> deletes environments older than <code>&lt;time&gt;</code> (e.g., <code>30d</code>)
* see our [[nix-env.md|nix-env]] page for a much more in-depth discussion of using <code>nix-env</code>


For completeness, lets add in the other usual version-control suspects.
= Advanced package usage =


{{Commands|prompt=[name@cluster:~]
Often we require a composition of packages. This can be as simple as having the binaries from multiple packages available in the same <code>bin</code> directory (e.g., <code>make</code>, <code>gcc</code>, and <code>ld</code> to build a simple C program) to as complex as having a python environment setup with all the desired modules installed (e.g., PYTHON_PATH set correctly, etc.).
|nix-env --install --attr nixpkgs.subversion nixpkgs.mercurial
|nix-env --query
}}


Actually, we probably don't really want subversion any more. Let's remove that.
All of these have a common format. You write a Nix expression in a <code>.nix</code> file that composes together packages in a file and then you tell the above commands to use that with the <code>-f &lt;nix file&gt;</code> option. For example, say the file <code>python.nix</code> has an expression for a python environment in it, you can create a per-project bin directory with


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[user@cluster:~]$ nix build -f python.nix -o python
|nix-env --uninstall subversion
[user@cluster:~]$ ./python/bin/python</source>
|nix-env --query
The Nix expression you put in the file generally
}}


= Environments =
* does <code>with import &lt;nixpkgs&gt; {}</code> to bring the set of nixpkgs into scope
* calls an existing package composition functions with a list of space-separated components to include


Nix keeps referring to user environments. Each time we install or remove packages we create a new environment based off of the previous environment.
The template for doing the second these follows below as it differs slightly across the various eco-systems.


== Switching between previous environments ==
A pro tip is


This means the previous environments still exist and we can switch back to them at any point. Let's say we changed our mind and want subversion back. It's trivial to restore the previous environment.
* there are many [https://nixos.org/nixpkgs/manual/#chap-language-support languages and framework supported] but only a few described here, send us an email if you would like a missing supported one added here


{{Commands|prompt=[name@cluster:~]
== Generic ==
|nix-env --rollback
|nix-env --query
}}


Of course we may want to do more than just move to the previous environment. We can get a list of all our environments so far and then jump directly to whatever one we want. Let's undo the rollback.
Nixpkgs provides a <code>buildEnv</code> function that combine multiple packages into a single ones (by combining their <code>bin</code>, <code>lib</code>, etc. directories). The list of packages are the same as used before minus the leading <code>nixpkgs</code> as it was imported (e.g., <code>git</code> instead of <code>nixpkgs.git</code>).


{{Commands|prompt=[name@cluster:~]
<source lang="nix">with import <nixpkgs> {};
|nix-env --list-generations
buildEnv {
|nix-env --switch-generation 4
  name = "my environment";
|nix-env --query
  paths = [
}}
    ... list of packages ...
  ];
}</source>
== Python ==


== Operations are atomic ==
Nixpkgs provides the following python related attributes


Due to the atomic property of Nix environments, we can't be left halfway through installing/updating packages. They either succeed and create us a new environment or leave us with the previous one intact.
* <code>python&lt;major&gt;&lt;minor&gt;</code> - a package providing the given python
* <code>python&lt;major&gt;&lt;minor&gt;.pkgs</code> - the set of python packages using the given python
* <code>python&lt;major&gt;&lt;minor&gt;.withPackages</code> - wraps python with <code>PYTHON_PATH</code> set to a given set of packages


Let's go back to the start when we just had Nix itself and install the one true GNU distributed version control system tla. Don't let it complete though. Hit it with <code>CTRL+c</code> partway through.
We can use the former directly to use the programs provided by python packages


{{Commands|prompt=[name@cluster:~]
<source lang="bash">[user@cluster:~]$ nix run python36.pkgs.spambayes
|nix-env --switch-generation 1
[user@cluster:~]$ sb_filter.py --help
|nix-env --install --attr nixpkgs.tla
[user@cluster:~]$ exit</source>
CTRL+c
and the later in a <code>.nix</code> file to create a python wrapper to enable a given set of libraries (e.g., a <code>python</code> command we can run and access the given set of python packages from)
}}


Nothing bad happens. The operation didn't complete so it has no effect on the environment whatsoever.
<source lang="nix">with import <nixpkgs> { };
python.withPackages (packages:
  with packages; [
    ... list of python packages ...
  ]
)</source>
Some pro tips are


{{Commands|prompt=[name@cluster:~]
* the aliases <code>python</code> and <code>python&lt;major&gt;</code> given default <code>python&lt;major&gt;&lt;minor&gt;</code> versions
|nix-env --query
* the aliases <code>pythonPackages&lt;major&gt;&lt;minor&gt;</code> are short for <code>python&lt;major&gt;&lt;minor&gt;.pkgs</code> (including default version variants)
|nix-env --list-generations
* the function <code>python&lt;major&gt;&lt;minor&gt;.pkgs.buildPythonPackage</code> can be used to build your own packages
}}


== Nix only does things once ==
== R ==


The install and remove commands take the current environment and create a new environment with the changes. This works regardless of which environment we are currently in. Let's create a new environment from our original environment by just adding git and mercurial.
Nixpkgs provides the following R related attributes


{{Commands|prompt=[name@cluster:~]
* <code>R</code> - a package providing R
|nix-env --list-generations
* <code>rstudio</code> - a package providing RStudio
|nix-env --install --attr nixpkgs.git nixpkgs.mercurial
* <code>rPackages</code> - the set of R packages
|nix-env --list-generations
* <code>rWrapper</code> - a wrapped R with <code>R_LIBS</code> set to a minimal set of packages
}}
* <code>rstudioWrapper</code> - a wrapped RStudio with <code>R_LIBS</code> set to a minimal set of packages


Notice how much much faster it was to install git and mercurial the second time? That is because the software already existed in the local Nix store from the previous installs so Nix just reused it.
We can use <code>rPackages</code> directly to examine the content of packages


== Garbage collection ==
<source lang="bash">[user@cluster:~]$ nix build rPackages.exams -o exams
[user@cluster:~]$ cat exams/library/exams/NEWS
[user@cluster:~]$ exit</source>
and the latter two can be overridden in a <code>.nix</code> file to create R and RStudio wrappers to enable a given set of libraries (e.g., a <code>R</code> or <code>rstudio</code> command we can run and access the given set of R packages from)


Nix periodically goes through and removes any software not accessible from any existing environments. This means we have to explicitly delete environments we don't want anymore so Nix is able to reclaim the space. We can delete specific environments or any sufficiently old.
<source lang="nix">with import <nixpkgs> { };
rWrapper.override {
  packages = with rPackages; [
    ... list of R packages ...
  ];
}</source>
A pro tips is


{{Commands|prompt=[name@cluster:~]
* the function <code>rPackages.buildRPackage</code> can be used to build your own R packages
|nix-env --delete-generations 30d
 
}}
== Haskell ==
 
Nixpkgs provides the following haskell related attributes
 
* <code>haskell.compiler.ghc&lt;major&gt;&lt;minor&gt;&lt;patch&gt;</code> - package providing the given ghc
* <code>haskell.packages.ghc&lt;major&gt;&lt;minor&gt;&lt;patch&gt;</code> - the set of haskell packages compiled by the given ghc
* <code>haskell.packages.ghc&lt;major&gt;&lt;minor&gt;&lt;patch&gt;.withPackages</code> - wraps ghc to enable the given packages
* <code>haskell.packages.ghc&lt;major&gt;&lt;minor&gt;&lt;patch&gt;.withHoogle</code> - wraps ghc to enable the given packages with hoogle and documentation indices
 
We can use the first directly to use programs provided by haskell packages
 
<source lang="bash">[user@cluster:~]$ nix run haskell.packages.ghc864.pandoc
[user@cluster:~]$ pandoc --help</source>
and the last two in a <code>.nix</code> file create a ghc environment to enable a given set of package (e.g., a <code>ghci</code> we can run and access the given set of packages from)
 
<pre>with import &lt;nixpkgs&gt; { };
haskell.packages.ghc864.withPackages (packages:
  with packages; [
    ... list of Haskell packages ...
  ];
}</pre>
Some pro tips are
 
* the alias <code>haskellPackages</code> gives a default <code>haskell.packages.ghc&lt;major&gt;&lt;minor&gt;&lt;patch&gt;</code>
* the attributes in <code>haskell.lib</code> contains a variety of useful attributes for tweaking haskell packages (e.g., enabling profiling, etc.)
* the upstream maintainer has a useful [https://www.youtube.com/watch?v=KLhkAEk8I20 youtube video] on how to fix broken haskell packages
 
== Emacs ==
 
Nixpkgs provides the following emacs related attributes (append a <code>Ng</code> suffix for older versions of nixpkgs, e.g., <code>emacs25Ng</code> and <code>emacs25PackagesNg</code>)
 
* <code>emacs&lt;major&gt;&lt;minor&gt;</code> - a package providing the given emacs editor
* <code>emacs&lt;major&gt;&lt;minor&gt;Packages</code> - the set of emacs packages for the given emacs editor
* <code>emacs&lt;major&gt;&lt;minor&gt;Packages.emacsWithPackages</code> - wraps emacs to enable the given packages
 
We can use the second directly examine the content of packages
 
<source lang="bash">[user@cluster:~]$ nix build nixpkgs.emacs25Packages.magit -o magit
[user@cluster:~]$ cat magit/share/emacs/site-lisp/elpa/magit*/AUTHORS.md
[user@cluster:~]$ exit</source>
and the last one in a <code>.nix</code> file create an emacs with the given set of packages enabled
 
<pre>with import &lt;nixpkgs&gt; { };
emacs25Packages.emacsWithPackages (packages:
  with packages; [
    ... list of emacs packages ...
  ];
}</pre>
Some pro tips are
 
* the aliases <code>emacs</code> and <code>emacsPackages</code> give a default <code>emacs&lt;major&gt;&lt;minor&gt;</code> and <code>emacsPackages&lt;major&gt;&lt;minor&gt;</code> version
* the alias <code>emacs&lt;major&gt;&lt;minor&gt;WithPackages</code> are short for <code>emacs&lt;major&gt;&lt;minor&gt;Packages.emacsWithPackages</code> (including default version variants)


[[Category:Software]]
[[Category:Software]]

Revision as of 21:06, 30 July 2020


This article is a draft

This is not a complete article: This is a draft, a work in progress that is intended to be published into an article, which may or may not be ready for inclusion in the main wiki. It should not necessarily be considered factual or authoritative.




Overview

Nix is a package manager system that allows users to manage their own persistent software environments. At the moment it is only available on SHARCNET systems (i.e., graham and legacy). If you would like this to change, help motivate an expansion by letting us known (it requires some coordination, but isn't too difficult to do).

  • Supports one-off, per-project, and per-user usage of packages
  • Packages can be built, installed, upgraded, downgraded, and removed as a user
  • Operations either succeed or fail leaving everything intact (operations are atomic).
  • Extremely each to add and share packages

NOTE: The message failed to lock thread to CPU XX is a harmless warning that can be ignored.

Enabling and disabling the Nix environment

The user’s current Nix environment is enabled by loading the nix module. This creates some ’‘.nix*’’ files and sets some environment variables.

[name@cluster:~]$ module load nix

It is disabled by unloading the nix module. This unsets the environment variables but leaves the ’‘.nix*’’ files alone.

[name@cluster:~]$ module unload nix

Completely resetting the Nix environment

Most operations can be undone with the --rollback option (i.e., nix-env --rollback or nix-channel --rollback). Sometimes it is useful to entirely reset nix though. This is done by unloading the module, erasing all user related nix files, and then reloading the module file.

[name@cluster:~]$ module unload nix
[name@cluster:~]$ rm -fr ~/.nix-profile ~/.nix-defexpr ~/.nix-channels ~/.config/nixpkgs
[name@cluster:~]$ rm -fr /nix/var/nix/profiles/per-user/$USER /nix/var/nix/gcroots/per-user/$USER
[name@cluster:~]$ module load nix

Basic package usage

The nix search command can be used to locate available packages

[user@cluster:~]$ nix search git
...
* nixpkgs.git (git-minimal-2.19.3)
  Distributed version control system
...

Pro tips include

  • you need to specify -u after upgrading your package set (this will take awhile)
  • the search string is actually a regular expression and multiple ones are ANDed together

Often we want to use a package in one of three ways: a one-time command Individual packages can be access in Nix in a variety of ways

One offs

If you just want to use a package once, the easiest was is to use the nix run command. This command will start a shell in which PATH has been extended to include the specified package

[user@cluster:~]$ nix run nixpkg.git
[user@cluster:~]$ git
[user@cluster:~]$ exit

Note that this does not protect the package from being garbage collected overnight (e.g., the package is only guaranteed to be around temporarily for your use until sometime in the wee-morning hours). Pro tips include

  • you can specify more than one package in the same nix run command
  • you can specify a command instead of a shell with -c <cmd> <args> ...

Per-project

If you want to use a program for a specific project, the easiest way is with the nix build command. This command will create a symbolic link (by default named result) from which you can access the programs bin directory to run it.

[user@cluster:~]$ nix build nixpkgs.git
[user@cluster:~]$ ./result/bin/git

Note that (currently) the package will only be protected from overnight garbage collection if you output the symlink into your home directory and do not rename or move it. Pro tips include

  • you can specify the output symlink name with the -o <name> option
  • add the bin directory to your PATH to not have to type it in every time

Per-user

Loading the nix module adds the per-user common ~/.nix-profile/bin directory to your PATH. You can add and remove packages from this directory with the nix-env command

[user@cluster:~]$ nix-env --install --attr nixpkgs.git
[user@cluster:~]$ nix-env --query
git-minimal-2.19.3
[user@cluster:~]$ nix-env --uninstall git-minimal
uninstalling 'git-minimal-2.19.3'
[user@cluster:~]$ nix-env --query

Each command actually creates a new version, so all prior versions remain and can be used

[user@cluster:~]$ nix-env --list-generations
   1   2020-07-29 13:10:03
   2   2020-07-29 13:11:52   (current)
[user@cluster:~]$ nix-env --switch-generation 1
[user@cluster:~]$ nix-env --query
git-minimal-2.19.3
[user@cluster:~]$ nix-env --switch-generation 2
[user@cluster:~]$ nix-env --query

Pro tips include

  • nix-env --rollback moves up one generation
  • nix-env --delete-generations <time> deletes environments older than <time> (e.g., 30d)
  • see our nix-env page for a much more in-depth discussion of using nix-env

Advanced package usage

Often we require a composition of packages. This can be as simple as having the binaries from multiple packages available in the same bin directory (e.g., make, gcc, and ld to build a simple C program) to as complex as having a python environment setup with all the desired modules installed (e.g., PYTHON_PATH set correctly, etc.).

All of these have a common format. You write a Nix expression in a .nix file that composes together packages in a file and then you tell the above commands to use that with the -f <nix file> option. For example, say the file python.nix has an expression for a python environment in it, you can create a per-project bin directory with

[user@cluster:~]$ nix build -f python.nix -o python
[user@cluster:~]$ ./python/bin/python

The Nix expression you put in the file generally

  • does with import <nixpkgs> {} to bring the set of nixpkgs into scope
  • calls an existing package composition functions with a list of space-separated components to include

The template for doing the second these follows below as it differs slightly across the various eco-systems.

A pro tip is

Generic

Nixpkgs provides a buildEnv function that combine multiple packages into a single ones (by combining their bin, lib, etc. directories). The list of packages are the same as used before minus the leading nixpkgs as it was imported (e.g., git instead of nixpkgs.git).

with import <nixpkgs> {};
buildEnv {
  name = "my environment";
  paths = [
    ... list of packages ...
  ];
}

Python

Nixpkgs provides the following python related attributes

  • python<major><minor> - a package providing the given python
  • python<major><minor>.pkgs - the set of python packages using the given python
  • python<major><minor>.withPackages - wraps python with PYTHON_PATH set to a given set of packages

We can use the former directly to use the programs provided by python packages

[user@cluster:~]$ nix run python36.pkgs.spambayes
[user@cluster:~]$ sb_filter.py --help
[user@cluster:~]$ exit

and the later in a .nix file to create a python wrapper to enable a given set of libraries (e.g., a python command we can run and access the given set of python packages from)

with import <nixpkgs> { };
python.withPackages (packages:
  with packages; [
    ... list of python packages ...
  ]
)

Some pro tips are

  • the aliases python and python<major> given default python<major><minor> versions
  • the aliases pythonPackages<major><minor> are short for python<major><minor>.pkgs (including default version variants)
  • the function python<major><minor>.pkgs.buildPythonPackage can be used to build your own packages

R

Nixpkgs provides the following R related attributes

  • R - a package providing R
  • rstudio - a package providing RStudio
  • rPackages - the set of R packages
  • rWrapper - a wrapped R with R_LIBS set to a minimal set of packages
  • rstudioWrapper - a wrapped RStudio with R_LIBS set to a minimal set of packages

We can use rPackages directly to examine the content of packages

[user@cluster:~]$ nix build rPackages.exams -o exams
[user@cluster:~]$ cat exams/library/exams/NEWS
[user@cluster:~]$ exit

and the latter two can be overridden in a .nix file to create R and RStudio wrappers to enable a given set of libraries (e.g., a R or rstudio command we can run and access the given set of R packages from)

with import <nixpkgs> { };
rWrapper.override {
  packages = with rPackages; [
    ... list of R packages ...
  ];
}

A pro tips is

  • the function rPackages.buildRPackage can be used to build your own R packages

Haskell

Nixpkgs provides the following haskell related attributes

  • haskell.compiler.ghc<major><minor><patch> - package providing the given ghc
  • haskell.packages.ghc<major><minor><patch> - the set of haskell packages compiled by the given ghc
  • haskell.packages.ghc<major><minor><patch>.withPackages - wraps ghc to enable the given packages
  • haskell.packages.ghc<major><minor><patch>.withHoogle - wraps ghc to enable the given packages with hoogle and documentation indices

We can use the first directly to use programs provided by haskell packages

[user@cluster:~]$ nix run haskell.packages.ghc864.pandoc
[user@cluster:~]$ pandoc --help

and the last two in a .nix file create a ghc environment to enable a given set of package (e.g., a ghci we can run and access the given set of packages from)

with import <nixpkgs> { };
haskell.packages.ghc864.withPackages (packages:
  with packages; [
    ... list of Haskell packages ...
  ];
}

Some pro tips are

  • the alias haskellPackages gives a default haskell.packages.ghc<major><minor><patch>
  • the attributes in haskell.lib contains a variety of useful attributes for tweaking haskell packages (e.g., enabling profiling, etc.)
  • the upstream maintainer has a useful youtube video on how to fix broken haskell packages

Emacs

Nixpkgs provides the following emacs related attributes (append a Ng suffix for older versions of nixpkgs, e.g., emacs25Ng and emacs25PackagesNg)

  • emacs<major><minor> - a package providing the given emacs editor
  • emacs<major><minor>Packages - the set of emacs packages for the given emacs editor
  • emacs<major><minor>Packages.emacsWithPackages - wraps emacs to enable the given packages

We can use the second directly examine the content of packages

[user@cluster:~]$ nix build nixpkgs.emacs25Packages.magit -o magit
[user@cluster:~]$ cat magit/share/emacs/site-lisp/elpa/magit*/AUTHORS.md
[user@cluster:~]$ exit

and the last one in a .nix file create an emacs with the given set of packages enabled

with import <nixpkgs> { };
emacs25Packages.emacsWithPackages (packages:
  with packages; [
    ... list of emacs packages ...
  ];
}

Some pro tips are

  • the aliases emacs and emacsPackages give a default emacs<major><minor> and emacsPackages<major><minor> version
  • the alias emacs<major><minor>WithPackages are short for emacs<major><minor>Packages.emacsWithPackages (including default version variants)