[Nix-dev] Platform matching, accept/reject

[Nathaniel Griswold]

Hi all,

I'm interested in building with both pure and nonpure environments on
the same machine using nix. The motivation for this is i'd like the
expressiveness, ease of unprivileged deployment provided by nix to
build not only pure tools, but also to build and cache several
system-dependent libraries and tools that do /not/ depend on the nix
store at all (but are also not system packages or necessarily built in
VMs). It seems nix could be very helpful in expressing this controlled
impurity and even scanning for unwanted store dependencies.

As an example, maybe i want to build some software with an impure env
that depends on system glibc and several system libraries for both
debian 4 and debian 5. I decide that i don't want to build or nix-env
install the impure debian5 derivations on debian4 and vice versa.

Or maybe i want to build some packages with a pure glibc compiled
against an older kernel for maximum compatibility across my different
linux systems (and share them among all of them), but i i'd also like
to build some binaries with newer kernel headers and only run those on
systems running newer kernels (which i might statically define to be
doing so).

I'd also like to use this in a hetergenous, non-vm distributed build
environment.

It's trivial to pass different stdenvs into nixpkgs, or incorporate
pieces of the environment (such as /etc/issue on linux, or maybe some
hardware graphics card or cpu capability information) into the build
to distinguish the final hash, and make different build-time
assertions in the nix expression. But what about rejecting or
accepting distributed builds? You could use your scheduler to make
similar distinctions, but it seems the distinctions should be defined
by the nix expressions in question, not the scheduler. This would
provide consistent behavior for both distributed and command-line
builds. For example, i would want a test that depends on sse3 to be
rejected similarly when run as a distributed or local nix-instantiate
build, and to have the rejection in the distributed case be evaluated
without overhead.

x86_64 systems double as i686 systems using the personality() syscall,
but could there be a more general mechanism for overloading a node's
platform? I'm perfectly willing to define it statically and per-system
at the nix configuration level. It seems just allowing a system to
trust multiple platforms might be a very simple answer to all of the
above. Then the administrator could make completely arbitrary
distinctions on which systems will build which "platforms" (you can do
this right now but must pick exactly one platform for a given
evaluation AFAIK). Permuting different configuration.nix files would
be pretty annoying for builds going through daemons and a distributed
build environment.

Thanks for reading

-nate