[Nix-dev] GNU Guix 0.1 released (alpha)

Shea Levy shea at shealevy.com
Wed Jan 23 21:11:51 CET 2013


On 01/21/2013 05:39 AM, Ludovic Courtès wrote:
> Hi,
>
> Florian Friesdorf <flo at chaoflow.net> skribis:
>
>> Ludovic Courtès <ludo at gnu.org> writes:
>>> Florian Friesdorf <flo at chaoflow.net> skribis:
>>>> What are your thoughts on generating nix expressions from guix
>>>> expressions for the purpose of package definition?
>>> Do you mean the opposite–generating Guix expressions from Nix?
>> I actually meant guix -> nix, as guix being within a full language, I
>> had gut feeling this direction might be preferable, see also below.
> I think conversion has the same problem in both directions: simple
> meta-data is trivially converted, but anything beyond that, especially
> builder-side code, can hardly be automatically converted.
>
>>> Marc Weber <marco-oweber at gmx.de> skribis:
>>>>    - in which way you're going to utilize the new "power" of scheme first
>>>>      applying to what problems?
>>> On the build side, it nicely replaces Bash, and also Coreutils,
>>> Findutils, sed, and cURL.  :-)
>> Do you have ideas how these replacements could be used if generating nix
>> expressions from guix expressions?
> It’s going to be hard to automate anything.  For instance, something like
>
>    (substitute* (find-files "." "^Makefile$")
>      (("/bin/sh")
>       (which "sh")))
>
> would have to be converted to
>
>    find . -name Makefile -exec sed -i {} -e"s|/bin/sh|`which sh`|”
>
> Not to mention code that adds, removes, or modifies the standard build
> phases....
>
>>> It reuses the daemon, and thus libstore, as described in ‘README’.
>> I take that nix and guix nicely cooperatively use "/nix/store/" though
>> it's rather unlikely that the two would actually create the same output.
> Yes (I use it on top of NixOS currently.)
>
>> Would it be feasible to depend on nixpkgs from within guix packages?
> Yes, I did that in the beginning: you basically inject derivation paths
> as returned by ‘nix-instantiate’ into the derivations that Guix produces.
>
>> Would it be feasible to do it the other way round?
> In theory yes, because ‘import’ in the Nix language can import .drv
> files–a little-known feature.  ;-)
>
> In practice, though, it can only do that if the .drv defines an
> environment variable called ‘name’

Why do you say this? The import of .drv files doesn't look at the 
environment variables at all, it just sets drvPath and outPath 
(per-output) with the appropriate string contexts.

> , which Guix derivations don’t
> normally do.  (This is an example of how arguments to derivations are
> sometimes abused as arguments to the ‘derivation’ primitive.)
>
> Thanks,
> Ludo’.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



More information about the nix-dev mailing list