7 ms·

Nix 2.0 Released

278 points by jack_jennings 9y ago

eridius 9y ago
How do I upgrade my existing Nix installation? After updating the nixpkgs-unstable channel, nixpkgs.nix is still 1.11.16 (and nixpkgs.nixUnstable is a 2.0 pre-release).
- matthewbauer 9y ago
  Look up channels status here: http://howoldis.herokuapp.com http://howoldis.herokuapp.com It will prob take like 5 hours to be updated. Run nix-channel --update then reinstall nix.
  - eridius 9y ago
    Would it be safe to run `curl https://nixos.org/nix/install https://nixos.org/nix/install | sh` (safe as in it won't screw with my existing installed packages), and if so, will that get me Nix 2.0? Or do I still have to wait for nixpkgs-unstable to rebuild?
    - manveru 9y ago
      The easiest way is probably to do following: git clone https://github.com/nixos/nixpkgs cd nixpkgs git checkout origin/nix-2.0 nix-env -i $(nix-build --no-out-link . -A nix)
    - thomastjeffery 9y ago
      If you already have Nix installed, what you want to do is change the channel, and do an upgrade.
      - eridius 9y ago
        Change the channel to what? It's already on nixpkgs-unstable.
        HIPisTheAnswer 9y ago
        nix.package = pkgs.nixUnstable;
  - eridius 9y ago
    nixpkgs-unstable was updated 4 hours ago. Still doesn't have Nix 2.0. This strikes me as very strange. Why was Nix 2.0 released without updating nixpkgs?
- taohansen 9y ago
  You can upgrade right now with `nix.package = pkgs.nixUnstable;` in your `~/.nixpkgs/config.nix` [1] or on the command-line: `nix-channel --add https://nixos.org/channels/nixos-unstable https://nixos.org/channels/nixos-unstable nixos` followed by `nix-channel --update` if on any system but NixOS or `nixos-rebuild switch` if on NixOS. [1] https://ebzzry.io/en/nix/#nixpkgsconfiguration https://ebzzry.io/en/nix/#nixpkgsconfiguration
  - eridius 9y ago
    As I mentioned in my comment, nixpkgs.nixUnstable shows up as a 2.0 pre-release (specifically, nix-2.0pre5968_a6c0b773).
- clhodapp 9y ago
  It looks like Nix 2.0 is tagged[1] but nixpkgs isn't updated yet[2] [1] https://github.com/NixOS/nix/releases/tag/2.0 https://github.com/NixOS/nix/releases/tag/2.0 [2] https://github.com/NixOS/nixpkgs/blob/472dd33ea4905d562d9380d42ff09365e4b79a7e/pkgs/tools/package-management/nix/default.nix#L117-L137 https://github.com/NixOS/nixpkgs/blob/472dd33ea4905d562d9380...
zapita 9y ago
I love the core concepts behind Nix, and have great respect for their engineering abilities. However I am skeptical of their ability to achieve broad adoption beyond their current community of passionate experts. There are two reasons for my skepticism: 1. User experience. Unless you're one of the "passionate experts", the Nix user experience is pretty terrible. The learning curve is punishing compared to competing systems. 2. Elitist culture. In my experience, the Nix community is too smart for its own good. Their technical foundation is so far ahead of mainstream systems, and their technical design so satisfying to passionate experts, that they've forgotten how to live a day in the shoes of a mere mortal. Try pointing out flaws in the user experience, or the need to offer more pragmatic ways to migrate existing systems, and you will be met mostly with derision and reminders of Nix's superior engineering. But superior engineering is not everything. If you want to spread the amazing potential of Nix to everyone, then you need to compromise with a flawed, imperfect world. You need to meet users half-way, and guide them to the promised land, instead of waiting for them to show up on their own. Otherwise someone will come along that will do it for you. All this is eerily similar to what happened to functional programming communities.
- taohansen 9y ago
  Except that Docker et al are already that compromised solution. No need to replicate. And for what it's worth, the #nixos community is one of the kindest, most helpful communities I've ever encountered. Stop by and ask your questions!
  - zapita 9y ago
    > Except that Docker et al are already that compromised solution. No need to replicate. I think you're right that Docker has embraced the "meet half-way" school of thought (maybe too much?). But that doesn't mean they have exclusivity over the approach. Docker lacks many of the features that make Nix so powerful. On the other hand Docker is much more pleasant to use, for me at least. If a tool came along that combined the simplicity of Docker with the power of Nix, I would probably stop using both, and just use that. I think Nix itself could be that tool... if only they fixed the issues I described above.
vishvananda 9y ago
I have been using nix for a while to build binary packages for crashcart[1] and I really love the premise of isolated source-based builds. Unfortunately, over time I've become quite frustrated with the pull-everything from the internet model. If you are building packages from scratch each time instead of pulling down cached version using the nix command, the build breaks quite often. Mostly it is silly stuff like the source package disappearing from the net. A particularly egregious offender is the named.root[2] file being updated, which will cause everything to fail to build until the sha is updated in the build def. I don't know that there is a great solution for this problem. Maybe there needs to be a CI system that does from scratch build of all of the packages every day and automatically files bugs. Alternatively, a cache of sources and not just built packages could ease the pain. This issue probably affects ver few nix users, but it has demoted my love of nix down to "still likes but is somewhat annoyed by". [1]: https://github.com/oracle/crashcart https://github.com/oracle/crashcart [2]: https://www.internic.net/domain/named.root https://www.internic.net/domain/named.root
- clhodapp 9y ago
  What about running your own caching HTTP proxy for your build's external dependencies or else pulling static copies of these dependencies into your own repo? It seems like the problem isn't building everything from source but rather that the sources of truth for the inputs are unreliable. You'd have the same problem trying to build e.g. Debian from scratch if you couldn't reliably pull down all the sources for things.
  - vishvananda 9y ago
    A caching http proxy would help me build the same things reliably, but it wouldn't help anyone else who cloned my repository and attempted to do their own build unless I also gave them access to the proxy. And it hides the fact that the standard from-scratch build doesn't actually work. I think the cached nix packages is why it takes so long for some of these issues to be discovered. The difference with Debian (and other linuxes) is that the source code for the build is also provided. The upstream source might be from random place on the net, but Debian provides a source package that you can use to rebuild the binary package. Maybe the solution is for nix/nixos to provide something similar.
alexashka 9y ago
This looks really nice. For basic users who have a DigitalOcean droplet with Ubuntu, to run a web server - how does this compare?
- FreedomWarrior 9y ago
  To do a car analogy (this is Slashdot, right?): With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be really difficult. With NixOS, it's like 3D printing a new car every time. You'll design a model, press a button, and the car gets built from scratch. If you don't like it, tweak the design a bit, and print a new car. If the new car breaks, just go back to the previous known-good one, which is already in your garage. You can even take the design documents to your friend and generate an exactly identical model.
  - rlpb 9y ago
    > With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be really difficult. You can do it that way, but I wouldn't recommend it. If your Ubuntu system becomes that way, it has become unmaintainable. All modern server deployment methods describe the deployment in code so you do "print a new car" every time you change something. This includes Ubuntu. On the desktop, you largely don't need to pop open the hood at all. If you find yourself doing that, you have yourself an experimental system and not production system.
    - majewsky 9y ago
      > On the desktop, you largely don't need to pop open the hood at all. So you're not installing updates on desktop machines at all? That sounds incredibly dangerous.
      - rlpb 9y ago
        Huh? No. Updates ship as part of Ubuntu. From your perspective, updates happen. You don't need to pop open the hood at all to get them.
thinkpad20 9y ago
As a nix user for several years this is pretty exciting. I hadn’t been following the 2.0 development, but I was really hoping to see a mention of support for something like a .gitignore equivalent when hashing directories from the filesystem. Seems that that isn’t in this release :(
- dtzWill 9y ago
  If what you're dealing with is actually a git repository, in 2.0 you can just use "src = fetchGit ./.;"-- this is what the expression for building Nix itself does :). Otherwise you can use filterSource (documented in the linked article, the Nix manual) to roll your own filtering. If you have any problems with either of these I encourage you to join #nixos on freenode and ask. Hope this helps! :)
- lukego 9y ago
  Have you seen the library function cleanSource() and related routines? I use these for excluding files (e.g. by filename extension) from being visible in builds. This might suit your use case too. https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix
  - thinkpad20 9y ago
    Yeah, and I use cleanSource, but I find it to be pretty obtuse and full of edge cases.
thomastjeffery 9y ago
Finally, a better command-line interface! Hopefully, this means I can stop using the website search for packages.
- Filligree 9y ago
  Have you tried the 'nox' package?
deleted 9y ago
[deleted]
Lilian_Lee 9y ago
> It introduces a new command named nix, which is intended to eventually replace all nix-* commands with a more consistent and better designed user interface This is pretty nice. I've been using nix on my Mac for more than a year now, it works well on mac. But the separated commands are not easy to remember and the help documentation is also separated. This change really improves command line UX
TremendousT 9y ago
Heh- after a many years haitus from running any kind of UNIX/Linux at home, I was thinking about installing a Linux based distro and NixOS was near the top of my list to try. How does this 2.0 Nix release effect a new install of NixOS- should I wait a bit for a corresponding overhaul of NixOS to come out? I suspect theoretically it's not necessary, but wondering if NixOS will be tracking this Nix release in some way shortly... Anyone know?
- manveru 9y ago
  Yes, NixOS 18.03 will be released soon, featuring Nix 2.0. You can still install the current 17.09 or unstable and upgrade it later by simply switching your channel.
  - TremendousT 9y ago
    Great- thanks.
- deleted 9y ago
  [deleted]
- pxc 9y ago
  I upgraded my personal laptop to NixOS 18.03 (currently still nixos-unstable; the release branch hasn't been cut) a week ago and I've had no problems You can switch which version of Nix you're using whenever you want, and you can install multiple versions of Nix side-by-side if you want to, just like with any other package. To install Nix 2.0 on an older release of Nixpkgs/NixOS, just use the package `nixUnstable`. You can install it with `nix-env` if you want to try it out right now. The only real differences between a typical upgrade and upgrading between releases are: 1. You'll need more storage space for the course of the upgrade, because most of your dependencies have been updated. 2. You might have to change your config up a little, because a few packages have been removed, renamed, or are out of date. You still get all the nice rollback features that you're used to, and if Nix 1.x is part of your old system profile and 2.0 part of your new one, when you roll back, Nix will roll back, too. To more directly answer your question: NixOS 18.03 will indeed include Nix 2.0.
tarruda 9y ago
It appears that by using a CoW filesystem like Btrfs I can have some of the same advantages of using Nix: - Parallel installation of multiple OSes sharing the same storage pool - Snapshot/rollback How does using Nix compare to using a CoW filesystem such as Btrfs or Zfs?
- rekado 9y ago
  The main difference is that functional package management lets you declare the system state. Free rollbacks are a consequence of being able to fully describe the system state. With a file system the storage pool is dumb and all meaning of higher-order abstractions (such as packages) is lost. You don't use functional package management just for deduplication, but in order to be able to declare and reason about state. (I work on Guix, which is an implementation of functional package management, but with different abstractions.)
  - michaelmrose 9y ago
    What are the advantages of guix vs nix?
    - rekado 9y ago
      As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix: - Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by GuixSD (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth. - Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc. - Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions. - Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API. - Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en https://hal.inria.fr/hal-01580582/en - Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, sablevm, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme. - GuixSD, the GNU system distribution built around Guix. GuixSD has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. GuixSD provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library. - I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.) - It's GNU. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix and GuixSD to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing. On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after reading SICP); it seems to be the other way around with Nix. Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects. Let me end with a comment that's actually on topic for the original post: Congratulations on the Nix 2.0 release! Long live functional package management!
Ixiaus 9y ago
Very exciting release notes. Nix is great and this makes it even better.
bfrog 9y ago
It looks like they're at least attempting to work towards user friendliness, which is by far my biggest complaint. My other big complaint is that when something goes wrong its damn near impossible to figure it out. Trying to figure out why I couldn't get postgres working with postgis was nightmarish last year sometime when I last tried nixos. I'm still really optimistic that this will someday replace arch for me. I just don't know when
canadaduane 9y ago
That's a really impressive list of contributors. 99 if I've counted correctly.
alphaalpha101 9y ago
Why would I want to use this over Guix?
lukego 9y ago
Hurray! I love Nix and I have been looking forward to this new makeover of the UI with the 'nix' command. It seems like the original command line usages developed incrementally over time, making them quirky and inconsistent, and so it is really welcome to have them redone based on long experience. (Thanks, Nix hackers!) Seeing this released as Nix 2.0 is a really lovely surprise for me this morning :).
hedning 9y ago
I guess this is a good place to plug the fairly new bash completion support for Nix (including Nix 2.0)[1]. For those like me who can't stand using a cli without completion. [1] https://github.com/hedning/nix-bash-completions https://github.com/hedning/nix-bash-completions

278 points by jack_jennings 9y ago

How do I upgrade my existing Nix installation? After updating the nixpkgs-unstable channel, nixpkgs.nix is still 1.11.16 (and nixpkgs.nixUnstable is a 2.0 pre-release).

matthewbauer 9y ago
Look up channels status here: http://howoldis.herokuapp.com http://howoldis.herokuapp.com It will prob take like 5 hours to be updated. Run nix-channel --update then reinstall nix.
- eridius 9y ago
  Would it be safe to run `curl https://nixos.org/nix/install https://nixos.org/nix/install | sh` (safe as in it won't screw with my existing installed packages), and if so, will that get me Nix 2.0? Or do I still have to wait for nixpkgs-unstable to rebuild?
  - manveru 9y ago
    The easiest way is probably to do following: git clone https://github.com/nixos/nixpkgs cd nixpkgs git checkout origin/nix-2.0 nix-env -i $(nix-build --no-out-link . -A nix)
  - thomastjeffery 9y ago
    If you already have Nix installed, what you want to do is change the channel, and do an upgrade.
    - eridius 9y ago
      Change the channel to what? It's already on nixpkgs-unstable.
      - HIPisTheAnswer 9y ago
        nix.package = pkgs.nixUnstable;
- eridius 9y ago
  nixpkgs-unstable was updated 4 hours ago. Still doesn't have Nix 2.0. This strikes me as very strange. Why was Nix 2.0 released without updating nixpkgs?
taohansen 9y ago
You can upgrade right now with `nix.package = pkgs.nixUnstable;` in your `~/.nixpkgs/config.nix` [1] or on the command-line: `nix-channel --add https://nixos.org/channels/nixos-unstable https://nixos.org/channels/nixos-unstable nixos` followed by `nix-channel --update` if on any system but NixOS or `nixos-rebuild switch` if on NixOS. [1] https://ebzzry.io/en/nix/#nixpkgsconfiguration https://ebzzry.io/en/nix/#nixpkgsconfiguration
- eridius 9y ago
  As I mentioned in my comment, nixpkgs.nixUnstable shows up as a 2.0 pre-release (specifically, nix-2.0pre5968_a6c0b773).
clhodapp 9y ago
It looks like Nix 2.0 is tagged[1] but nixpkgs isn't updated yet[2] [1] https://github.com/NixOS/nix/releases/tag/2.0 https://github.com/NixOS/nix/releases/tag/2.0 [2] https://github.com/NixOS/nixpkgs/blob/472dd33ea4905d562d9380d42ff09365e4b79a7e/pkgs/tools/package-management/nix/default.nix#L117-L137 https://github.com/NixOS/nixpkgs/blob/472dd33ea4905d562d9380...

zapita 9y ago

I love the core concepts behind Nix, and have great respect for their engineering abilities. However I am skeptical of their ability to achieve broad adoption beyond their current community of passionate experts. There are two reasons for my skepticism: 1. User experience. Unless you're one of the "passionate experts", the Nix user experience is pretty terrible. The learning curve is punishing compared to competing systems. 2. Elitist culture. In my experience, the Nix community is too smart for its own good. Their technical foundation is so far ahead of mainstream systems, and their technical design so satisfying to passionate experts, that they've forgotten how to live a day in the shoes of a mere mortal. Try pointing out flaws in the user experience, or the need to offer more pragmatic ways to migrate existing systems, and you will be met mostly with derision and reminders of Nix's superior engineering. But superior engineering is not everything. If you want to spread the amazing potential of Nix to everyone, then you need to compromise with a flawed, imperfect world. You need to meet users half-way, and guide them to the promised land, instead of waiting for them to show up on their own. Otherwise someone will come along that will do it for you. All this is eerily similar to what happened to functional programming communities.

taohansen 9y ago
Except that Docker et al are already that compromised solution. No need to replicate. And for what it's worth, the #nixos community is one of the kindest, most helpful communities I've ever encountered. Stop by and ask your questions!
- zapita 9y ago
  > Except that Docker et al are already that compromised solution. No need to replicate. I think you're right that Docker has embraced the "meet half-way" school of thought (maybe too much?). But that doesn't mean they have exclusivity over the approach. Docker lacks many of the features that make Nix so powerful. On the other hand Docker is much more pleasant to use, for me at least. If a tool came along that combined the simplicity of Docker with the power of Nix, I would probably stop using both, and just use that. I think Nix itself could be that tool... if only they fixed the issues I described above.

vishvananda 9y ago

I have been using nix for a while to build binary packages for crashcart[1] and I really love the premise of isolated source-based builds. Unfortunately, over time I've become quite frustrated with the pull-everything from the internet model. If you are building packages from scratch each time instead of pulling down cached version using the nix command, the build breaks quite often. Mostly it is silly stuff like the source package disappearing from the net. A particularly egregious offender is the named.root[2] file being updated, which will cause everything to fail to build until the sha is updated in the build def. I don't know that there is a great solution for this problem. Maybe there needs to be a CI system that does from scratch build of all of the packages every day and automatically files bugs. Alternatively, a cache of sources and not just built packages could ease the pain. This issue probably affects ver few nix users, but it has demoted my love of nix down to "still likes but is somewhat annoyed by". [1]: https://github.com/oracle/crashcart https://github.com/oracle/crashcart [2]: https://www.internic.net/domain/named.root https://www.internic.net/domain/named.root

clhodapp 9y ago
What about running your own caching HTTP proxy for your build's external dependencies or else pulling static copies of these dependencies into your own repo? It seems like the problem isn't building everything from source but rather that the sources of truth for the inputs are unreliable. You'd have the same problem trying to build e.g. Debian from scratch if you couldn't reliably pull down all the sources for things.
- vishvananda 9y ago
  A caching http proxy would help me build the same things reliably, but it wouldn't help anyone else who cloned my repository and attempted to do their own build unless I also gave them access to the proxy. And it hides the fact that the standard from-scratch build doesn't actually work. I think the cached nix packages is why it takes so long for some of these issues to be discovered. The difference with Debian (and other linuxes) is that the source code for the build is also provided. The upstream source might be from random place on the net, but Debian provides a source package that you can use to rebuild the binary package. Maybe the solution is for nix/nixos to provide something similar.

alexashka 9y ago

This looks really nice. For basic users who have a DigitalOcean droplet with Ubuntu, to run a web server - how does this compare?

FreedomWarrior 9y ago
To do a car analogy (this is Slashdot, right?): With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be really difficult. With NixOS, it's like 3D printing a new car every time. You'll design a model, press a button, and the car gets built from scratch. If you don't like it, tweak the design a bit, and print a new car. If the new car breaks, just go back to the previous known-good one, which is already in your garage. You can even take the design documents to your friend and generate an exactly identical model.
- rlpb 9y ago
  > With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be really difficult. You can do it that way, but I wouldn't recommend it. If your Ubuntu system becomes that way, it has become unmaintainable. All modern server deployment methods describe the deployment in code so you do "print a new car" every time you change something. This includes Ubuntu. On the desktop, you largely don't need to pop open the hood at all. If you find yourself doing that, you have yourself an experimental system and not production system.
  - majewsky 9y ago
    > On the desktop, you largely don't need to pop open the hood at all. So you're not installing updates on desktop machines at all? That sounds incredibly dangerous.
    - rlpb 9y ago
      Huh? No. Updates ship as part of Ubuntu. From your perspective, updates happen. You don't need to pop open the hood at all to get them.

thinkpad20 9y ago

As a nix user for several years this is pretty exciting. I hadn’t been following the 2.0 development, but I was really hoping to see a mention of support for something like a .gitignore equivalent when hashing directories from the filesystem. Seems that that isn’t in this release :(

dtzWill 9y ago
If what you're dealing with is actually a git repository, in 2.0 you can just use "src = fetchGit ./.;"-- this is what the expression for building Nix itself does :). Otherwise you can use filterSource (documented in the linked article, the Nix manual) to roll your own filtering. If you have any problems with either of these I encourage you to join #nixos on freenode and ask. Hope this helps! :)
lukego 9y ago
Have you seen the library function cleanSource() and related routines? I use these for excluding files (e.g. by filename extension) from being visible in builds. This might suit your use case too. https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix https://github.com/NixOS/nixpkgs/blob/master/lib/sources.nix
- thinkpad20 9y ago
  Yeah, and I use cleanSource, but I find it to be pretty obtuse and full of edge cases.

thomastjeffery 9y ago

Finally, a better command-line interface! Hopefully, this means I can stop using the website search for packages.

Filligree 9y ago
Have you tried the 'nox' package?

deleted 9y ago

[deleted]

Lilian_Lee 9y ago

> It introduces a new command named nix, which is intended to eventually replace all nix-* commands with a more consistent and better designed user interface This is pretty nice. I've been using nix on my Mac for more than a year now, it works well on mac. But the separated commands are not easy to remember and the help documentation is also separated. This change really improves command line UX

TremendousT 9y ago

Heh- after a many years haitus from running any kind of UNIX/Linux at home, I was thinking about installing a Linux based distro and NixOS was near the top of my list to try. How does this 2.0 Nix release effect a new install of NixOS- should I wait a bit for a corresponding overhaul of NixOS to come out? I suspect theoretically it's not necessary, but wondering if NixOS will be tracking this Nix release in some way shortly... Anyone know?

manveru 9y ago
Yes, NixOS 18.03 will be released soon, featuring Nix 2.0. You can still install the current 17.09 or unstable and upgrade it later by simply switching your channel.
- TremendousT 9y ago
  Great- thanks.
deleted 9y ago
[deleted]
pxc 9y ago
I upgraded my personal laptop to NixOS 18.03 (currently still nixos-unstable; the release branch hasn't been cut) a week ago and I've had no problems You can switch which version of Nix you're using whenever you want, and you can install multiple versions of Nix side-by-side if you want to, just like with any other package. To install Nix 2.0 on an older release of Nixpkgs/NixOS, just use the package `nixUnstable`. You can install it with `nix-env` if you want to try it out right now. The only real differences between a typical upgrade and upgrading between releases are: 1. You'll need more storage space for the course of the upgrade, because most of your dependencies have been updated. 2. You might have to change your config up a little, because a few packages have been removed, renamed, or are out of date. You still get all the nice rollback features that you're used to, and if Nix 1.x is part of your old system profile and 2.0 part of your new one, when you roll back, Nix will roll back, too. To more directly answer your question: NixOS 18.03 will indeed include Nix 2.0.

tarruda 9y ago

It appears that by using a CoW filesystem like Btrfs I can have some of the same advantages of using Nix: - Parallel installation of multiple OSes sharing the same storage pool - Snapshot/rollback How does using Nix compare to using a CoW filesystem such as Btrfs or Zfs?

rekado 9y ago
The main difference is that functional package management lets you declare the system state. Free rollbacks are a consequence of being able to fully describe the system state. With a file system the storage pool is dumb and all meaning of higher-order abstractions (such as packages) is lost. You don't use functional package management just for deduplication, but in order to be able to declare and reason about state. (I work on Guix, which is an implementation of functional package management, but with different abstractions.)
- michaelmrose 9y ago
  What are the advantages of guix vs nix?
  - rekado 9y ago
    As one of the co-maintainers of GNU Guix I'm obviously biased, but here's what I consider some important unique features of Guix: - Guix is all written in Guile Scheme (with the exception of parts of the inherited daemon, which hasn't yet been completely implemented in Guile); this extends to development tools like importers, updaters, to user tools like "guix environment", and even bleeds into other projects that are used by GuixSD (the GNU system distribution built around Guix), such as the shepherd init system. There is a lot of code reuse across the stack, which makes hacking on Guix really fun and smooth. - Packages are first class citizens in Guix. In Nix the idea of functional package management is very obvious in the way that packages are defined, namely as functions. These functions take their concrete inputs from an enormous mapping. In Guix you define first-class package values as Scheme variables. These package values reference other package values, which leads to a lazily constructed graph of packages. This emergent graph can be used as a library to trivially build other tools like "guix graph" (for visualising the graph in various ways) or "guix web" (for a web interface to installing and searching packages), "guix refresh" (for updating package definitions), a lovely feature-rich Emacs interface etc. - Embedded DSL. Since Guix is written in Scheme---a language for writing languages---it was an obvious choice to embed the package DSL in the host language Scheme instead of implementing a separate language that needs a custom interpreter. This is great for hacking on Guix, because you can use all the tools you'd use for Scheme hacking. There's a REPL, great Emacs support, a debugger, etc. With its support for hygienic macros, Scheme is also a perfect vehicle to implement features like monads (we use a monadic interface for talking to the daemon) and to implement other convenient abstractions. - Graph rewriting. Having everything defined as regular Scheme values means that you can almost trivially go through the package graph and rewrite things, e.g. to replace one variant of a package with a different one. Your software environment is just a Scheme value and can be inspected or precisely modified with a simple Scheme API. - Code staging. Thanks to different ways of quoting code (plain S-expressions and package-aware G-expressions), we use Scheme at all stages: on the "host side" as well as on the "build side". Instead of gluing together shell snippets to be run by the daemon we work with the AST of Scheme code at all stages. If you're interested in code staging I recommend reading this paper: https://hal.inria.fr/hal-01580582/en https://hal.inria.fr/hal-01580582/en - Bootstrapping. Some of us are very active in the "bootstrappable builds" community (see http://bootstrappable.org http://bootstrappable.org) and are working towards full bootstrap paths for self-hosting compilers and build systems. One result is a working bootstrap path of the JDK from C (using jikes, sablevm, GNU classpath, jamvm, icedtea, etc). In Guix we take bootstrapping problems serious and prefer to take the longer way to build things fully from source instead of just adding more binary blobs. This means that we cannot always package as many things as quickly as others (e.g. Java libraries are hard to build recursively from source). I'm currently working on bootstrapping GHC without GHC and without the generated C code, but via interpreting a variant of GHC with Hugs. Others are working on bootstrapping GCC via Scheme. - GuixSD, the GNU system distribution built around Guix. GuixSD has many features that are very different from NixOS. The declarative configuration in Scheme includes system facilities, which also form a graph that can be inspected and extended; this allows for the definition of complex system facilities that abstract over co-dependent services and service configurations. GuixSD provides more Scheme APIs that apply to the whole system, turning your operating system into a Scheme library. - I like the UI of Guix a lot more than that of Nix. With Nix 2.0 many perceived problems with the UI have been addressed, of course, but hey, I still prefer the Guix way. I also really like the Emacs interface, which is absolutely gorgeous. (What can I say, I live in Emacs and prefer rich 2D buffers over 1D command line strings.) - It's GNU. I'm a GNU hacker and to me Guix is a representative of a modern and innovative GNU. It's great to see more GNU projects acting as one within the context of Guix and GuixSD to provide an experience that is greater than the sum of its parts. Work on Guix affected other GNU packages such as the Hurd, Guile, cool Guile libraries, and led to a bunch of new GNU packages such as a workflow language for scientific computing. On the other hand, although Guix has a lot of regular contributors and is very active, Nix currently has more contributors than Guix. Guix is a younger project. The tendency to take bootstrapping problems very seriously means that sometimes difficult packages require more work. Oddly, Guix seems to attract more Lispers than Haskellers (I'm a recovering Haskeller who fell in love with Scheme after reading SICP); it seems to be the other way around with Nix. Having said all that: Nix and Guix are both implementations of functional package management. Both projects solve similar problems and both are active in the reproducible builds efforts. Solutions that were found by Nix devs sometimes make their way into Guix and vice versa. The projects are not competing with one another (there are orders of magnitudes more people out there who use neither Guix nor Nix than there are users of functional package managers, so there's no point in trying to get people who use Nix to switch to Guix). At our recent Guix fringe event before FOSDEM Eelco Dolstra (who invented functional package management and Nix) gave a talk on the future of Nix surrounded by Guix hackers --- there is no rivalry between these two projects. Let me end with a comment that's actually on topic for the original post: Congratulations on the Nix 2.0 release! Long live functional package management!

Ixiaus 9y ago

Very exciting release notes. Nix is great and this makes it even better.

bfrog 9y ago

It looks like they're at least attempting to work towards user friendliness, which is by far my biggest complaint. My other big complaint is that when something goes wrong its damn near impossible to figure it out. Trying to figure out why I couldn't get postgres working with postgis was nightmarish last year sometime when I last tried nixos. I'm still really optimistic that this will someday replace arch for me. I just don't know when

canadaduane 9y ago

That's a really impressive list of contributors. 99 if I've counted correctly.

alphaalpha101 9y ago

Why would I want to use this over Guix?

lukego 9y ago

Hurray! I love Nix and I have been looking forward to this new makeover of the UI with the 'nix' command. It seems like the original command line usages developed incrementally over time, making them quirky and inconsistent, and so it is really welcome to have them redone based on long experience. (Thanks, Nix hackers!) Seeing this released as Nix 2.0 is a really lovely surprise for me this morning :).

hedning 9y ago

I guess this is a good place to plug the fairly new bash completion support for Nix (including Nix 2.0)[1]. For those like me who can't stand using a cli without completion. [1] https://github.com/hedning/nix-bash-completions https://github.com/hedning/nix-bash-completions