If the given programs are packaged with nix then it shouldn't be an issue but I agree that for starting random programs it's not ideal. Maybe the solution it to make it dead easy to wrap a Java program in a derivation ?
On Mon, 7 Mar 2016 at 01:51 Svein Ove Aas <svein....@aas.no> wrote: > That's effectively what happens already, if you use nix-shell. > > I'm concerned mostly about users who don't know to do that. Someone trying > to run a script from a different brand of unix, for example. > > In theory, if there is a java binary on the PATH, there should also be a > JAVA_HOME. That's Oracle's take on this, but... well, I prefer Nix to have > as few surprises as possible. > > On Sun, Mar 6, 2016 at 8:12 PM zimbatm <zimb...@zimbatm.com> wrote: > >> What if the JRE(s) also included a `java-env.sh` that can be sourced ? >> Then it's easy to build wrappers that source it dynamically. >> >> On Sat, 5 Mar 2016 at 17:34 Svein Ove Aas <sve...@gmail.com> wrote: >> >>> Context: https://github.com/NixOS/nixpkgs/issues/13653 >>> >>> There are a few packages which can't be considered properly installed >>> (and usable) without setting environment variables, this example being the >>> Java development kit. >>> >>> Some Java-based tools need to know where to find the JDK. The way they >>> do this is by looking at the JAVA_HOME environment variable. That is... >>> currently, it isn't set at all, unless you use nix-shell or an equivalent >>> mechanism. >>> >>> I've thought of a couple of solutions, but would welcome other >>> suggestions. In no particular order... >>> >>> (The problem is not restricted to just JAVA_HOME.) >>> >>> - Wrapping the the JDK binaries with makeWrapper. >>> This is a non-starter, as it's common to use JAVA_HOME in scripts. >>> >>> - JAVA_HOME is set in the JDK's setup-hook. We can source that file on >>> shell startup. >>> This works well for nix-shell, and is the approach I've chosen to take >>> globally for a temporary fix. Unfortunately, it is in a sense even worse >>> than the status quo. Since this produces a pointer into /nix/store, the >>> value of JAVA_HOME in a running shell can become invalid because the JDK in >>> question is GC'd (!), or superseded by a newer one *without* being deleted >>> (!!). >>> >>> - Adding another directory under /run, containing symlinks that we can >>> mutate. >>> Has the obvious problem of impurity, but we're talking about system >>> (or user) profiles; they're already impure, in the same sense. I don't see >>> any technical issues here, but that doesn't mean there aren't any. I'm not >>> sure how to implement it, or even whether I should. >>> We'd have "JAVA_HOME=/run/env/JAVA_HOME", or so. >>> >>> One further concern... >>> >>> - Right now, the only way to install Java system-wide is to put it in >>> environment.systemPackages. Or using nix-env. Either way, JAVA_HOME >>> wouldn't get set; this is true even with that PR. I've been trying to think >>> of ways to fix this, but I have no idea how. Send help! >>> As a result, even if I add programs.java to NixOS, it doesn't help >>> anyone who's got the problem right now. >>> >>> .... >>> >>> I'd like to implement a general solution for all such situations, >>> ideally one that would get merged. Rant over, though. Thoughts? >>> >> _______________________________________________ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev