[Nix-dev] A few questions from a NixOS newbie.

[Kirill Elagin]

On Mon, Apr 21, 2014 at 4:23 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk>wrote:

>
> nix-channel --add http://nixos.org/channels/nixos-unstable nixos
>
> seems to work but is probably not what I want (getting few-minutes-old
> fixes from nixpkgs git repository).
>

There is a thing called Hydra. It runs tests and builds packages. If all
the tests passed it updates the channel. Sometimes there are problems in
master and the channel doesn't get updated for quite some time.
If you want few-minutes old fixes and you are ok with building everything
on your own (instead of getting already built substitutes from the
channedl), you'll have to do nixos-rebuild against your local repo with
`nixos-rebuild -I nixpkgs=</path/to/nixpkgs/repo>`.

* The nix packages don't seem to be versioned in any way. On Gentoo, I
> could inspect the software in the tree: I could check the version of the
> software itself, and the version of the e-build. An example use case is
> if the software fetch source dies: we need to update the e-build and
> bump its version but the software version stays the same. Is there an
> equivalent in NixOS?
>

Right, nix packages are not really versioned. Most of the time there is
exactly one version of each package in the tree (with a few exceptions).
To check the version you'll have to look at the nix expression.


> * What is the proper way to integrate own packages into the tree?
> Yesterday I found it necessary to try and package a (proprietary ;( )
> blob which amongst some other things needs patchelf &c. What I did was
> to fork then clone nixpkgs and written the package in appropriate
> directory. I now don't know how to work with this repository so that the
> rest of the system sees it. What I did was cd to the repository and then
> use nix-env -f . -i mypackage but I fear that as soon as I go back to
> using nix-env -i outside of that repository, nix will be confused: it
> had newer packages a second ago and now it's back to old!
>

This should work fine.
If you want to have a package just for yourself, you can add it via
`~/.nixpkgs/config` (keyword for Google: `packageOverrides`).

* In my aforementioned package, there's a binary that I expected to be
> able to run after nix-env -i. That's however not the case. Is there a
> section that's necessary in the .nix file that tells nix which files
> should be made visible? I looked at some other packages briefly but
> didn't see much.
>

Nix adds links to your `~/.nix-profile`, well, almost heuristically. So if
your package when built produces some files in $out/bin/, those will be
linked.
Just ensure that `~/.nix-profile/{s,}bin` is in PATH and that you run `hash
-r` (if it is needed).


> * The versioning displayed seems to be a bit weird:
>
> ✗ 1 lenalee shana % nix-env -qa | grep xmonad
> haskell-xmonad-contrib-ghc7.6.3-0.11.2
> haskell-xmonad-contrib-ghc7.6.3-0.11.2
> haskell-xmonad-contrib-ghc7.6.3-0.11.2-profiling
> haskell-xmonad-extras-ghc7.6.3-0.12
> haskell-xmonad-extras-ghc7.6.3-0.12
> haskell-xmonad-extras-ghc7.6.3-0.12-profiling
> haskell-xmonad-ghc7.6.3-0.11
> haskell-xmonad-ghc7.6.3-0.11
> haskell-xmonad-ghc7.6.3-0.11-profiling
>
> Here we have multiple packages which display the same version (why?) and
> some -profiling packages. What is the naming scheme followed? Does the
> version start at the last `-%d'? How do I check the difference between
> the packages that display in the same fashion?
>

Just add `-P`.

% nix-env -qaP | grep
xmonad
~/proj/nixpkgs
nixos.pkgs.haskellPackages.xmonadContrib
haskell-xmonad-contrib-ghc7.6.3-0.11.2
nixos.pkgs.haskellPackages_ghc763_no_profiling.xmonadContrib
haskell-xmonad-contrib-ghc7.6.3-0.11.2
nixos.pkgs.haskellPackages_ghc763_profiling.xmonadContrib
haskell-xmonad-contrib-ghc7.6.3-0.11.2-profiling
nixos.pkgs.haskellPackages_ghc763_no_profiling.xmonadExtras
haskell-xmonad-extras-ghc7.6.3-0.12
nixos.pkgs.haskellPackages.xmonadExtras
haskell-xmonad-extras-ghc7.6.3-0.12
nixos.pkgs.haskellPackages_ghc763_profiling.xmonadExtras
haskell-xmonad-extras-ghc7.6.3-0.12-profiling
nixos.pkgs.haskellPackages_ghc763_no_profiling.xmonad
haskell-xmonad-ghc7.6.3-0.11
nixos.pkgs.haskellPackages.xmonad
haskell-xmonad-ghc7.6.3-0.11
nixos.pkgs.haskellPackages_ghc763_profiling.xmonad
haskell-xmonad-ghc7.6.3-0.11-profiling

in `pkgs/top-level/all-packages;nix` you'll see

haskellPackages = haskellPackages_ghc763;

so, basically, the two are the same.


> * How can I find out more about packages? For example, I'd like to query
> a package of a license, or to see its .nix file. Someone told me on IRC
> how to do the second one but it involved grepping all-packages.nix,
> getting the path from there and then opening that. Is there no mechanism
> in place which can tell me more about a package? I'd expect at least the
> information given by the `eix' tool on Gentoo: installed and available
> versions, short description, homepage and license. It seems to me like
> fairly basic and useful information.
>

Unfortunately, that's the way to go now. Grep `all-packages.nix`, find
expression path, and open it.


>  * Sometimes when I nixos-rebuild switch --upgrade, I get messages about
> clashing packages. Unfortunately I don't have the messages on hand
> because it doesn't always happens (only seems to happen when there are
> things to actually update). How did I get myself into this mess and how
> do I fix it? I am guessing it's either one of the two: running nix-env
> -f . -i ... in the nixpkgs git checkout while being on a channel that's
> less up-to-date *or* the fact that I switched architectures from 64-bit
> to 32-bit and now nix is confused about the packages from each both
> being present.
>

Do you mean collisions? That's fine, some packages provide the same files.
In case there is no error, just ignore it.
If there is an error, it will tell you what to do (set priority).


> * Regarding USE, I quite liked the functionality. For those unaware, USE
> flags let you toggle some options to do with the package. As Gentoo is
> source-based, this pretty much always simply changed the compilation
> flags. This provided great flexibility: one can choose whether they want
> ALSA or Gnome or KDE or taglib or test or whatever support for each
> package and the dependencies would be pulled in (or left out)
> accordingly. As far as I know, there is no such system in place for nix.
> Say I wanted to install emacs but didn't want a graphical environment:
> it's a perfectly valid use case to want to run emacs on your headless
> VPS. Yet, if I were to just nix-env -i emacs, I would be prompted to
> install gtk3, Xorg and who knows what else (I have not actually tried
> but this is simply for demonstration purposes). In Gentoo I can simply
> set the -gtk3 and -X flags and any software that allows me to switch
> those off will do so. How do I achieve this on NixOS? As far as I can
> tell, one has to effectively make their own emacs package that removes
> all the things we don't want along with their dependencies and then
> install that. This is of course a problem: a lot of hassle, anything
> depending on emacs doesn't see that we now have it, even if we convince
> things depending on emacs that we do now have it, they might actually
> depend on emacs with gtk3 and so on and so on. What's the way this
> problem is solved on NixOS? If I wanted to use NixOS on any of my
> servers, just this stops it from me doing so.
>

You've already googled for `packageOverrides`, right?


>  * I found myself needing older glibc yesterday. Namely, I wanted glibc
> 2.17. Normally I would be very wary of changing my glibc version but I
> thought nix can make this easy for me and if something breaks I can just
> use an older configuration anyway, right? To my surprise, I only found
> glibc 2.19 in nix-env -qa! How do I access older packages? I honestly
> don't think that only glibc 2.19 was every packaged which means the
> older version was there somewhere. Does -qa hide it from me? Was it
> removed from the tree and if yes, why? If `it would make -qa' messy is
> the answer, maybe the way looking for packages works should be
> rethought. I honestly hope I'm not expected to package glibc 2.17 myself
> after about a day of usage...
>

So, as I said, most packages have just one version in the tree.


>  * Assuming I managed to get glibc 2.17 in the tree, how do I use 2.17
> for some packages but 2.19 for the rest? For example, I could make the
> packages that require 2.17 depend on it, but then when I try to install
> them, nix will either refuse me because it would break everything
> depending on 2.19 or it would install it and break everything. I suppose
> I'm asking about how to sandbox packages. I hear nix-shell is something
> that might be applicable here but I'm unsure.
>

You probably can get older expressions, and build the packages you need
with older version (remember `packageOverrides`).
I don't think installing one standalone package with older version of glibc
will break something (I've never tried, though).

* Unfortunately about half of the software that I used in the past seems
> to be missing and I assure you I didn't use much software at all. While
> I'm not blaming anyone and realise I'll most likely have to package it
> all myself, what is the procedure of getting your packages back into the
> official channels? With Gentoo, one would file a request to include
> software in the tree on the bug tracker and then wait. We'd provide an
> e-build if we wanted to speed things up a bit but after that, it's the
> packagers that take ownership of it. How is the situation in NixOS? I
> write the package then what? I imagine I send a pull request to nixpkgs
> on GitHub. If it gets merged, am I now responsible for it? Does anyone
> else take the blame when it's not up-to-date or broken?
>

That's it, pull request.
Packages have `maintainer` field, you are welcome to put yourself there for
expressions you created and for others without maintainers.
But you don't have to.
If it will get broken, it will be marked as broken and probably removed one
day if no one wants to maintain it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140421/d699a068/attachment-0001.html