On Fri, Jul 13, 2012 at 12:46 AM, Mathijs Kwik <[email protected]>wrote:
> Bryce L Nordgren <[email protected]> writes: > > > On Thu, Jul 12, 2012 at 12:40 PM, Mathijs Kwik <[email protected]> > 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
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
