5 ms·

It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, wh

by jolux 3y ago

It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, which is an entirely different interface over flakes. I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.

rgoulter 3y ago
> I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. Nix has a higher difficulty curve, and rougher corners, than most tools out there. The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?". Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything. > Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.
- jolux 3y ago
  > Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility. Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal. edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
  - rgoulter 3y ago
    I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software. https://www.nixhub.io/packages/erlang https://www.nixhub.io/packages/erlang Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install). > Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
    - jolux 3y ago
      > I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software Correct. > It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that. Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
      - rgoulter 3y ago
        > In what universe is it reasonable to make package consumers write software... Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`). I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile. With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is. In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs. > Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder. Yeah, Nix is much more difficult to use than other tools. Nix's UX is one where you pay a big cost upfront in order to save on effort later. e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.
pxc 3y ago
> DetSys already provides their own Nix installer That installer has actually been developed with community collaboration from outside DetSys from early on in its lifecycle via the Nix Installer Working Group¹, which includes stakeholders from other companies and whoever else volunteered to get involved. I haven't followed it super closely recently, but to the best of my knowledge DetSys has done a good job with that project of orienting themselves towards the wider community and upstreaming that work. FWIW, the maintainer of and chief contributor to that project is also extremely responsive to community activity on GitHub as well. I reported a few bugs the other day and was frankly delighted by how it went. It's being developed in the open, like proper open-source. The Determinate Nix Installer is not at all a 'let's do this in-house, behind closed doors, then throw it over the fence' kind of effort. -- 1: https://discourse.nixos.org/t/nix-installer-workgroup/21495/20 https://discourse.nixos.org/t/nix-installer-workgroup/21495/...
- jolux 3y ago
  Oh yeah, I have no criticisms with how that project is being run. But obviously they still decided to launch it instead of working to upstream it.
  - biggestlou 3y ago
    Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on. We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't. [1]: https://determinate.systems/posts/determinate-nix-installer#the-future-of-the-installer https://determinate.systems/posts/determinate-nix-installer#...
    - jolux 3y ago
soraminazuki 3y ago
Every piece of technology is incapable of doing anything if you label all solutions as "hacks." Here's proof: Is it possible to write C programs that manipulate strings? No, because string library functions are "hacks." Is it possible to write a bash script that passes arguments with spaces to a command? No, because quoting and character escaping are "hacks." Nix packages are malleable. With a bit of code, customizations can be applied to individual packages and entire dependency closures alike. An overlay is an embodiment of this property. It allows the user to create packages that fits their unique needs on the fly without having to repackage the whole world. No other package manager maybe besides Guix has this capability. I don't think it's fair to dismiss it as an "hack."

by jolux 3y ago

rgoulter 3y ago

> I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. Nix has a higher difficulty curve, and rougher corners, than most tools out there. The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?". Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything. > Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.

jolux 3y ago
> Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. Yeah, this is the part I find a bit silly. There should be one way to do this. What I want to do is pin an Erlang version (down to semver patch) and then pin an Elixir version that’s compatible with it (also to semver patch). This is trivial to do with my existing tools (asdf/rtx and Dockerfiles), but it doesn’t have first-class support in Nix. I have to build that capability myself! I was absolutely floored by this after hearing so much about how seriously Nix takes reproducibility. Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. The default Elixir just gets the latest release at the time nixpkgs was released. I can pin nixpkgs trivially but it’s not intuitive to pin individual packages across nixpkgs releases. Clearly this is just how Nix works, but because it’s not how any other dependency managers work, it’s a lot harder to integrate piecemeal. edit: to Jetpack’s credit, this is one of the things I really like about Devbox. It makes pinning minor versions easy!
- rgoulter 3y ago
  I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software. https://www.nixhub.io/packages/erlang https://www.nixhub.io/packages/erlang Note that this approach isn't without its downsides (compared to overriding the version in nixpkgs, or using a separate nix package). -- Mainly, since it uses an older nixpkgs version, the dependencies will also be that old version. (They won't have any security fixes which have been released since then; and it'll take up more disk space to install). > Similarly, the default Elixir and Erlang packages don’t even have a version, you have to use one of the special elixir_1_14 packages to get a specific minor version. Supporting multiple versions be more helpful at the cost of more effort to maintain. It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
  - jolux 3y ago
    > I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software Correct. > It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that. Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
    - rgoulter 3y ago
      > In what universe is it reasonable to make package consumers write software... Docker is also a tool where the UX is nicer if you write code (e.g. a Dockerfile) rather than using cli only (e.g. `docker commit`). I don't think there's anyone who would prefer to use `docker commit` instead of using a Dockerfile. With Nix, it's similar: only using Nix through the CLI, and not writing Nix code, is going to limit how useful Nix is. In any case, you don't need to write Nix code to use a package from an older revision of nixpkgs. -- With different options, there are different trade-offs. > Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? ... Tools are supposed to make our lives easier, not harder. Yeah, Nix is much more difficult to use than other tools. Nix's UX is one where you pay a big cost upfront in order to save on effort later. e.g. that's comparable in Infra-as-Code, where writing Terraform is going to be slower than just managing stuff through a graphical console.

pxc 3y ago

> DetSys already provides their own Nix installer That installer has actually been developed with community collaboration from outside DetSys from early on in its lifecycle via the Nix Installer Working Group¹, which includes stakeholders from other companies and whoever else volunteered to get involved. I haven't followed it super closely recently, but to the best of my knowledge DetSys has done a good job with that project of orienting themselves towards the wider community and upstreaming that work. FWIW, the maintainer of and chief contributor to that project is also extremely responsive to community activity on GitHub as well. I reported a few bugs the other day and was frankly delighted by how it went. It's being developed in the open, like proper open-source. The Determinate Nix Installer is not at all a 'let's do this in-house, behind closed doors, then throw it over the fence' kind of effort. -- 1: https://discourse.nixos.org/t/nix-installer-workgroup/21495/20 https://discourse.nixos.org/t/nix-installer-workgroup/21495/...

jolux 3y ago
Oh yeah, I have no criticisms with how that project is being run. But obviously they still decided to launch it instead of working to upstream it.
- biggestlou 3y ago
  Point of clarification: we are fully open to upstreaming the installer in whole or in part and have been from the get-go.[^1] But the installer is a pretty radical departure from the current official installer. The official installer is written in Bash; the DetSys installer is written in Rust. The official installer targets fairly "standard" platforms; the DetSys installer has experimental support for things like the SteamDeck. And so on. We think it's perfectly okay to have that kind of distribution of labor in OSS, where core/upstream things need to be extremely stable and conservative while the community runs experiments and figures out what works and doesn't. [1]: https://determinate.systems/posts/determinate-nix-installer#the-future-of-the-installer https://determinate.systems/posts/determinate-nix-installer#...
  - jolux 3y ago

soraminazuki 3y ago

Every piece of technology is incapable of doing anything if you label all solutions as "hacks." Here's proof: Is it possible to write C programs that manipulate strings? No, because string library functions are "hacks." Is it possible to write a bash script that passes arguments with spaces to a command? No, because quoting and character escaping are "hacks." Nix packages are malleable. With a bit of code, customizations can be applied to individual packages and entire dependency closures alike. An overlay is an embodiment of this property. It allows the user to create packages that fits their unique needs on the fly without having to repackage the whole world. No other package manager maybe besides Guix has this capability. I don't think it's fair to dismiss it as an "hack."