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/ _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev