[Nix-dev] Dependency Semantics

[Bryce L Nordgren]

On Fri, Jul 13, 2012 at 12:46 AM, Mathijs Kwik <mathijs at bluescreen303.nl>wrote:

> Bryce L Nordgren <bnordgren at gmail.com> writes:
>
> > On Thu, Jul 12, 2012 at 12:40 PM, Mathijs Kwik <mathijs at bluescreen303.nl>
> wrote:
>


> Your quest seems to not really lead to special/new/powerful properties,
> just saves a few cpu cycles, while (if not used wisely) undoing some of
> the properties of nix. If you really think it is worth it, sure, go on.
> As I've said before, I'm not _against_ it in general, because I know
> there are some pointless rebuilds, so there is something to gain. I'm
> just skeptical about the means to know/prove which rebuild are
> pointless, and about the "just try it by default, and if problems are
> found we can fix these" idea.
>
>
Interesting. At its heart, my quest is to do something reasonable for Java
(since I'm trying to package some code I need right now).  From that
perspective, Nix adds a whole lot of overhead and doesn't add much (if any)
value. In fact, since one of the major build systems is also a dependency
management system, Nix and Maven are fighting for control over the same
thing. The naive model of configure/make/make install doesn't detect
dependencies when the build system downloads all the dependencies into the
build dir without asking. But maven only downloads binaries, the POM does
not necessarily describe how to get the source, so cascading a build
automatically would be tricky. The biggest thing Nix could add, if it were
common to package java code in Nix expressions (thereby adding where to get
the source for each package), would be Nix rebuilds of a complete stack of
Java code. I'm not entirely sure how useful that is, since I expect that
the typical stack of java code is probably compiled on a mixture of Windows
and Linux platforms of varying configurations (e.g., vastly different
closures of system software), and even varying versions of the jdk. There
may be some value in assembling the jarfile dependencies into a single
directory for each app (each app gets its own "lib dir" profile with
successive generations). One of the big problems with Java is duplication:
every app distributes a complete set of required dependencies; Nix may be
equipped to address that.

Hashing this out with you, I think the most valuable thing I got out of
this is the concept of multiple sets of Nix expressions: one for each of
these synthetic, multiplatform environments. The boundary of each
environment is a "permeable membrane", which provides a degree of
isolation, but which also allows interaction with other environments.
Rather than thinking of this in terms of "weak" or "strong" dependencies,
I'm now envisioning this as allowing a package to declare membership in one
of these environments, then declare what it interacts with (depends on). It
could interact with other members of the same environment, "optional" parts
of the environment, or members of a different environment (e.g., system
level software). The policy on how to handle membership in these
environments (which are embedded in a running system) could be
configurable, and could have manual overrides. Most importantly, an
end-user's computer does not have to have the same policy as a Hydra
instance, and two end users with different tolerance for risk don't have to
agree on their policy settings.

I'd really like to see Nix add value to these synthetic environments--and
not just on NixOS. To use Nix as a build system on Windows may require that
the build system assume that "JDK 1.6" or "Python 2.7" is considered a
sufficient description of the environment, particularly if the machine is
not equipped to rebuild python itself. Nix is never going to be used to
rebuild Windows, but there's value in using it there to add better
dependency management. The starting point is different is all.

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120717/c21462e9/attachment.html