[Nix-dev] Improving the Developer Experience in the Nix Community

[Jeffrey Johnson]

> 
> On Jun 27, 2012, at 4:03 PM, Bryce L Nordgren wrote:
> 
>> 
>> 
>> On Wed, Jun 27, 2012 at 12:16 PM, Shea Levy <shea at shealevy.com> wrote:
>> 
>> > - On the level of Nix as a package manager, there is a way to roll back
>> > everything but GC
>> >
>> What do you mean, exactly? You can roll back versions of nix, and if you use build.nix in the nix source tree you can build each component as its own derivation...
>> I can't pretend to know what the original poster meant, but I'd want this at least to mean rolling back the stateful information maintained by a package too. (maybe by snapshotting the drive before upgrading in case things go south?)
>>  
> 
> The whole trick here is defining exactly what "stateful" means.
> 
>> > - There is a simple way to declare something an acceptable substitute of
>> > something else.
>> >
>> Do you mean substitute in the sense nix uses it, i.e. a way to realise a path without building it? Or something else?
>> I'd like to know if there's an analog to "provides" and "requires" in arch. So if a pure java package needs "a" java runtime environment, it shouldn't care whether the jre is provided by the Sun implementation or IcedTea or OpenJDK. It also shouldn't care about minor version numbers and may not care about major version numbers. If it's not pure Java, and there's native code it intends to link against a JVM, then it becomes bound to a particular implementation at instantiation time. Same thing for Ruby vs. Ruby-Enterprise.
>>  
> 
> Why would you want dependency assertions? Nix expressions are de facto encapsulations
> of a set of build elements that is a far stronger assertion framework than Provides: and Requires:
> (which involve issues of naming/versions/comparison thatr simply do not matter for nix).
> 
> I suspect that you are addicted to linux package managers from last century ;-)
> 
> 
>> Many webapps will need to specify that "a" database library is present, but may not care which one.
>>  
> 
> Heh: if the web app is so "careless" to not specify which database to use,
> there's no reason why other system components should care about a busted web app.
> 
>> A similar but not identical situation arises whenever an interface is defined which may have multiple implementations. A package may depend on the interface without depending on a particular implementation, however "something" sporting the interface must be available.
>>  
> 
> You aren't defining "interface" carefully enough to attempt a response here.
> 
>>  
>> 
>> > - There is a simple way to derive a version of package with dependency
>> > versions changed (for use with subsituters, mainly)
>> >
>> 
>> Can you expand on this here? How would such a feature help?
>> Should I have to recompile all my *.jar files just because I upgraded my runtime environment? I hope the answer is no! :)
>>  
> 
> The answer  depends on whether your runtime environment upgrade just broke your jar files.
> 
>>  
>> 
>> > - There is a way to replace subsituted package with a "better"
>> > substitution or native build
>> >
>> Continuing with a Java theme: the Java Advanced Imaging interfaces have a (default) pure java implementation as well as a native (accelerated) implementation.
>>  
> 
> If two application choices  are equivalent, then there is no basis for choice and either suffices.
> Coin flipping is as logical as any other choosing: revisit the meaning of "equivalent" if you don't
> like what the coin sez.
> 73 de Jeff
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120627/0621989c/attachment-0001.html