4 ms·

I don't work on projects where Docker is useful in production, but I've found it tremendously useful in continuous integration. It guarantees a reproducible env

by swift 10y ago

I don't work on projects where Docker is useful in production, but I've found it tremendously useful in continuous integration. It guarantees a reproducible environment, which a VM could do, but just as importantly it documents how to produce that environment from scratch. I've found that hugely valuable. I've always liked the idea of Nix but I've never used it. How easy is it to extract and understand the details of the environment you've constructed to build your project?

baq 10y ago
the problem is docker builds aren't really reproducible; e.g. if you're using ubuntu, you have to do apt-get update or your apt-get installs will fail with 404s. i also haven't used nix, but i hear it truly solves the problem.
chriswarbo 10y ago
> Docker... documents how to produce that environment from scratch. I've found that hugely valuable. > How easy is it to extract and understand the details of the [Nix] environment you've constructed to build your project? The "extract" part is easy: Nix uses a declarative language to describe the environment, so in that sense it's like docker, but more fine-grained: each package is built in isolation, and installed to a read-only filesystem. As far as "understanding the details", it depends on what you want to know. You can use "nix-shell" to enter a build environment in a shell, e.g. nix-shell -E 'some Nix expression' will enter the build environment of 'some Nix expression', nix-shell -p 'some Nix expression' will create an environment with 'some Nix expression' installed, etc. For example, I'm currently tracking down a space leak in a Haskell program by running the following command after each edit of the source code: nix-shell -p 'with import <nixpkgs> {}; profiledHaskellPackages.callPackage (runCabal2nix { url = ../myTester; }) { myDependency = profiledHaskellPackages.callPackage (runCabal2nix { url = ./.; }) {}; }' --run 'tester +RTS -M100M -xc' The command 'tester +RTS -M100M -xc' is a Haskell program which dies if it uses more than 100MB of heap, exposing the space leak and dumping a stack trace. This will be run in an environment containing Haskell packages built from the source code in "./." (the current directory, for "myDependency") and "../myTester" (for the "tester" command). These packages and all of their dependencies will be built with profiling enabled. Running this command over and over will just re-use the previously-built environment. If I edit the source in ./. or in ../myTester, Nix will notice that the hashes have changed, rebuild the packages and their dependents and make a new environment using those. This makes it easy for me to test potential fixes.

by swift 10y ago

baq 10y ago

the problem is docker builds aren't really reproducible; e.g. if you're using ubuntu, you have to do apt-get update or your apt-get installs will fail with 404s. i also haven't used nix, but i hear it truly solves the problem.

chriswarbo 10y ago

> Docker... documents how to produce that environment from scratch. I've found that hugely valuable. > How easy is it to extract and understand the details of the [Nix] environment you've constructed to build your project? The "extract" part is easy: Nix uses a declarative language to describe the environment, so in that sense it's like docker, but more fine-grained: each package is built in isolation, and installed to a read-only filesystem. As far as "understanding the details", it depends on what you want to know. You can use "nix-shell" to enter a build environment in a shell, e.g. nix-shell -E 'some Nix expression' will enter the build environment of 'some Nix expression', nix-shell -p 'some Nix expression' will create an environment with 'some Nix expression' installed, etc. For example, I'm currently tracking down a space leak in a Haskell program by running the following command after each edit of the source code: nix-shell -p 'with import <nixpkgs> {}; profiledHaskellPackages.callPackage (runCabal2nix { url = ../myTester; }) { myDependency = profiledHaskellPackages.callPackage (runCabal2nix { url = ./.; }) {}; }' --run 'tester +RTS -M100M -xc' The command 'tester +RTS -M100M -xc' is a Haskell program which dies if it uses more than 100MB of heap, exposing the space leak and dumping a stack trace. This will be run in an environment containing Haskell packages built from the source code in "./." (the current directory, for "myDependency") and "../myTester" (for the "tester" command). These packages and all of their dependencies will be built with profiling enabled. Running this command over and over will just re-use the previously-built environment. If I edit the source in ./. or in ../myTester, Nix will notice that the hashes have changed, rebuild the packages and their dependents and make a new environment using those. This makes it easy for me to test potential fixes.