[Nix-dev] JAVA_HOME and other environment variables

[zimbatm]

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.ove at 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 <zimbatm at 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 <sveina at 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 at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160307/20e76b83/attachment-0001.html