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

[Shea Levy]

On Jun 27, 2012, at 4:03 PM, Bryce L Nordgren <bnordgren at gmail.com> 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?)
>  
> > - 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.

It's not implemented, but it's not impractical to have something like that. It could be implemented with nix as it is today, or even better if Eelco is serious about https://github.com/NixOS/nix/issues/14 . We already automatically pass arguments to functions based on attribute names, we could do that based on other attributes as well.

> 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.
>  
> Many webapps will need to specify that "a" database library is present, but may not care which one.
>  
> 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.
>  
>  
> 
> > - 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! :)
>  

Depends on how the packaging is done. We tend toward tightly coupling components with their dependencies in nixpkgs, but it's not inherent in nix.

>  
> 
> > - 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.
>  
> Hope I'm not muddying the waters.
>  
> Bryce
>  
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120627/397e242a/attachment.html