On 1/17/12 6:34 PM, Phil Hagelberg wrote: > [email protected] (Ludovic Courtès) writes: > >> (Did you mean to reply to the list?) > Oops; I didn't notice it's one of _those_ kinds of lists. =) > >>> Looks great! Is this kept out of the nixpkgs-unstable channel simply >>> because it's packaging software that hasn't seen a stable release? >> It’s not Nixpkgs, it’s Emacs. :-) So it has its own channel, at >> <http://hydra.nixos.org/jobset/gnu/emacs-trunk/channel/latest/MANIFEST>. >> But you can’t really use it easily. > I don't understand the distinction. Is keeping it in its own channel > comparable to the way PPAs (Personal Package Archives) work in Ubuntu?
Not quite. Nixpkgs is a package repository (well, a package recipe repository), emacs is a text editor, and hydra is a continuous build system that, among other things, makes its build results available via a nix channel. AFAIK, the primary purpose of building nixpkgs with hydra is to have the latest packages easily downloadable for nixpkgs users. AFAIK, the primary purpose of building emacs with hydra is to do continuous integration testing of the latest emacs source code, with the existence of the emacs-trunk channel being just a happy side-effect. >>> I tried installing the closure with nix-store --import and it appeared >>> to place the files into /nix, but nothing emacs-related was added to my >>> path or placed in my profile. I'm sure I'm missing something obvious, >>> but it's not covered by the section on closures in the manual. >> Normally something like this should work: >> >> $ curl >> http://hydra.nixos.org/build/1822960/nix/closure/emacs-24.0.92.closure.gz | \ >> gunzip | sudo nix-store --import >> $ nix-env -i /nix/store/a8s8p6353sr0waq6290r4kbiljfjk3gx-emacs-24.0.92 >> >> This is what appears under “help” for “Nix closure” at >> <http://hydra.nixos.org/build/1822960>, with the addition of ‘sudo’ when >> running ‘nix-import’. > OK, great; thanks. I was just looking through the manual. I see now that > it's mentioned in the manual, but it's not very clear: > >> Then if you do any Nix operation, e.g. >> $ nix-env -i firefox >> and Nix has to build a path that it sees is already present in >> /mnt/nix, then it will just copy from there instead of building it >> from source. > I think this wording could be made stronger. It sounds like an optional > step, but in most cases importing the closure has no effect without > this, right? Anyway, when I do "nix-env -i emacs" as per the manual, it > pulls in Emacs 23 from the network rather than using the closure I > imported, so it's not quite right anyway. In the example in the manual, the path downloaded corresponds to the highest-versioned package named 'firefox' in the nixpkgs repo. In other words, nix has access to a nix expression that defines that firefox, it tries to build it, and sees its already built. In your example, you haven't told nix where to find the nix expression defining emacs, so nix has no way to see that the path you downloaded corresponds to 'emacs', so you have to specify the path directly. Trying 'nix-env -i emacs' will just build the version of emacs specified in nixpkgs, which is obviously not the snapshot version you downloaded. > > -Phil > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev HTH, Shea _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
