[Nix-dev] [***SPAM***] Re: Improving the Developer Experience in the NixCommunity

[Michael Raskin]

>> > Continuing with a Java theme: the Java Advanced Imaging interfaces have a
>> > (default) pure java implementation as well as a native (accelerated)
>> > implementation.
>> 
>> How should this be solved? Try find answers yourself. Its the same
>> problem M.R. talked about if buildfarm uses optimiziations your computer
>> doesn't support (or let it be a kernel not matching glibc. Then suddenly
>> touch does no longer work).
>> It was my understanding that this thread is about articulating the things perceived to be lacking in Nix which could serve as fodder for future development.
>
>Well, to be honest I was more hoping for suggestions about how to improve the developer community, policies, etc. rather than technical improvements. But ideas for those are always good too, so please keep discussing :)

Well, details of implementation are probably too early to discuss, but
it is a good idea to know who wants such functionality and why - this 
functionality allows to locally compromise some of the guarantees of the
purest Nix, so maybe some people are against giving such a tool to 
anyone (because it would make some part of nix-store more fragile).

>> These longer term things are not likely to be quickly answered.
>>  
>> ...and it's not the same thing at all. The Java app should only have to specify that JAI is present. There is zero benefit to rebuilding the app if the JAI implementation is switched. Rebuilding doesn't fix links, rebuilding doesn't change the application binary in any way except for the timestamp. Rebuilding in this circumstance is a pure waste of time, producing exactly the same thing you had at the beginning.
>> ...and Nix doesn't have a way to express that.
>Well, that's on purpose. The whole point of nix is explicitly defined dependencies. I understand what Michael is looking for, and I think it would be great if there was a way to do it as a temporary fix, but ultimately I think using nix in this way as a long-term solution is likely to lead to error.
>That being said, my suggestion about hash-rewriting to Michael would work just as well for this case.

I consider this functionality useful for a) testing b) quick 
application of security fixes. Both use cases are OK with system
administrator pushing the big red button.

Also, I mentioned that I want to be able to replace hackish 
substitutions with properly built packages later.

I (personally) do not think that tooling around this functionality is as
important as manual access to it. Tooling will grow naturally, as we see
the real extent of the problem in the wild.