[Nix-dev] Some beginner Nix/nixpkgs questions

[Alex Dean]

Thanks Eelco,

The strategy for a private repository sounds great - I will try and get
that working with nix-serve.

On reproducible deployments using git revisions - it solves the problem,
but it feels like a very "out-of-band" solution. For a given piece of
software, that software's version will evolve and the Nix expression for a
given version can of course evolve (be patched) too. Outsourcing that whole
matrix of semantic versioning to commits in the underlying version control
system feels frankly a bit odd for a package management system. To put it
another way: I am attracted to Nix by the promise of immutability, and then
I find that the main package repo is constantly being mutated and doesn't
have any built-in semantics around these mutations (delegating to git
instead).

If I'm misunderstanding, very happy to be set straight!

Thanks,

Alex

On Wed, Aug 5, 2015 at 12:16 PM, Eelco Dolstra <eelco.dolstra at logicblox.com>
wrote:

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



-- 
Co-founder
Snowplow Analytics <http://snowplowanalytics.com/>
The Roma Building, 32-38 Scrutton Street, London EC2A 4RQ, United Kingdom
+44 (0)203 589 6116
+44 7881 622 925
@alexcrdean <https://twitter.com/alexcrdean>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150805/5536d50d/attachment-0001.html