[Nix-dev] Some beginner Nix/nixpkgs questions
Eelco Dolstra
eelco.dolstra at logicblox.com
Wed Aug 5 13:16:48 CEST 2015
Hi,
On 05/08/15 12:33, Alex Dean wrote:
> On 1 - "We prefer having only the latest version when possible.". I don't think
> I understand this. If I am using Packer to build an Amazon AMI and install Kafka
> via Nix, then all it takes is a single commit to Nixpkgs for me to end up with a
> different Kafka version on an image built on Tuesday to an image built on
> Monday. I understand the concept of "always deploy the latest XXX available",
> but the presumption of it is unworkable from a devops perspective.
To get reproducible deployments, you wouldn't use the latest version of Nixpkgs,
but a specific version.
For example,
$ nix-env -f
https://github.com/NixOS/nixpkgs/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz
-iA hello
installs GNU Hello from Nixpkgs revision 8a3eea05. So that will always give you
the same version of Hello.
To add your own packages or versions of packages missing in Nixpkgs, you *can*
create a private branch of Nixpkgs. But another way is to write a Nix expression
for your packages that builds upon Nixpkgs. For example:
with import (fetchTarball
https://github.com/NixOS/nixpkgs/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz)
{};
pkgs // {
oldHello = stdenv.mkDerivation {
name = "hello-2.6";
src = fetchurl {
url = http://ftp.gnu.org/gnu/hello/hello-2.6.tar.xz;
sha256 = "1f4901a723gg876c50f0siiq1ki4ls0xl7ngi2dh4dm4h3idygbl";
};
};
}
Now "nix-env -f expr.nix -iA oldHello" will install hello 2.6, while "nix-env -f
expr.nix -iA hello" will install 2.9.
Regarding *why* Nixpkgs generally only contains one version of a package: this
is for maintainability (e.g. it would be bad if we had to backport a security
fix to dozens of old versions of a package) and cost (it wouldn't be feasible
for our continuous build system to create binaries for all those old versions).
> 3. How do I operate a private repository of packages?
This would be done by distributing the Nix expressions for your packages to the
machines via whatever means you like (Git, rsync, ...), and setting up a "binary
cache" to ensure that machines don't have to build those packages from source.
One way is to build the packages on a central machine and run "nix-serve" to
make its Nix store available to the other machines via HTTP. See
http://nixos.org/nix/manual/#ssec-binary-cache-substituter for details.
Another method is to use "nix-push" to create a binary cache that can be served
statically. See http://nixos.org/nix/manual/#sec-nix-push for examples.
--
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
More information about the nix-dev
mailing list