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

[Florian Friesdorf]

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'd rather maintain packages in one (E)DSL, than two.

> If so, there’s the guix-import program, which works like this:
>
>   guix-import /path/to/nixpkgs attribute
>
> It spits out a basic Guix package definition.  By “basic”, I mean that
> only trivial things are converted; Bash snippets added in
> ‘configurePhase’, ‘preCheck’, etc. are just ignored.

I don't see us writing bash -> guix tranformations...

Ludovic Courtès <ludo at gnu.org> writes:
> A nice thing is that Scheme can be used both on the “host” side (as a
> replacement of the Nix language), and on the build side (a nice
> replacement of Bash...).
>

> Philosophically, I’m also interested in making a free software, and a
> “GNU” distro.

+1

> 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?

> On the host side, it facilitates the implementation of new tools.  For
> instance, listing the available packages, searching them, using l10n’d
> package descriptions, etc. is easy and fast.  The auto-updater that’s in
> the works, based on Nixpkgs’s gnupdate, is going to be both easier to
> implement and faster (no need to parse several MiBs of a low-level XML
> representation!).

sounds great!

> Guix provides access to several levels of API: store RPCs, low-level
> derivations, Scheme derivations, and high-level package descriptions.
> That opens up a wide range of possibilities, I think.  Again, this is
> the typical advantage of using a single language.

+1

> There’s also a clearer separation of concerns: for instance,
> env. vars. are not abused as arguments to the ‘derivation’ primitive.
>
>>   - how exactly you reuse existing "nix*" software. You should describe
>>     this.
>
> 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.

Would it be feasible to depend on nixpkgs from within guix packages?
Would it be feasible to do it the other way round?

>>   - what would be the advantages of your system - eg will you keep the
>>     lazy feature? If you build 150 packages its not a big problem.
>
> Of course it’s lazy, it doesn’t try to build every package as soon as
> you fire it.  :-)
>
> More details can be found in the manual, ‘README’, and in my GHM talk
> linked from the web site.
>
> Hope this clarifies things!

Helped me a lot!

thx!
-- 
Florian Friesdorf <flo at chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20130121/17676bd5/attachment.bin