[Nix-dev] Toward a Purer stdenv

[Michael Raskin]

>I've been thinking about creating a nixpkgs branch to find and eliminate 
>some of the remaining impurities in the Linux stdenv. Before I get 
>started, I wanted to poll the list with a few questions that will shape 
>how I go about things.
>
>1. What impurities does the current stdenv have? I can think of three 
>off of the top of my head: timestamps in files, kernel version (e.g. via 
>uname), and /bin/sh.

Obviously, we should only care about builds with all paranoid options
(like chroot) on. I am not sure that on non-NixOS systems we don't get
entire /bin/ in chroot... Fortunately, most of things fail because of
missing /lib/. Something that checks existence of /bin/rm still can 
fail.

Processor having or not having some features (think MPlayer MMX
hand-optimized loops in assembler language) - no idea if it is possible
to fight that. 

We have _deliberate_ optional impurity about parallelBuilds. You didn't
notice it because it is a secret feature with double opt-in (you need
to enable it on command line, and then for individual packages).

If something tries to do a networking test, it can be in for a lot of
fun - for example, a random port can be occupied or not on host. This
seems to require something on the level of lxc to prevent. CLisp has
network module tests by default.

We pass /dev/ inside chroot as-is. There are many readable sources of
disaster there. I am not sure foozjs doesn't have a mode where it tries
to detect your printer during installation.

Of course, resource exhaustion is another set of questions... 

>2. What kind of testing should I set up to see that my changes actually 
>remove impurities?

For most of impurities it is trivial to implement special builder

It could get the information you want to be inaccessible and write it to
output.

>3. When might it be desirable to have impurities? I can think of three 
>cases: When knowledge of the performance of the system could potentially 
>speed up a build (e.g. knowing how many cores the CPU has for parallel 
>building), when knowledge of the performance of the system is necessary 
>for a test (e.g. checking that running a certain tool completes its task 
>in the right amount of time), and when a build would otherwise fail. My 
>current view is that the first two cases are OK as long as the 
>impurities (preferably provably) don't affect the output (think 
>unsafePerformIO), and that the for the third case we should attempt to 
>fix the build system in question if possible and should explicitly 
>include whatever system information is being accessed as a dependency if 
>not. Ideally our build system would give us ways to purposely allow 
>impurities when they are of the first two types, such as the 
>enableParallelBuilding variable the generic builder currently recognizes.

In the really really ideal world I would like first kind of impurity
to be fully manageable from Nix command line and the second kind to be
split off in a separate -tests package with fixed output (namely: 
empty). Fixed-output impurities are OK, I guess.