Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

github.com

Post reply on HN
Print view View original

51–60 of 186 posts

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#51

Post by colordrops »

predictabl3 wrote: post #42
bergkvist wrote: post #23

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…

>You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding This is decidely not quite true. You must have the file visible to Git. Flakes still just uses the files, as long as they're tracked by git. As long as you have no new files that aren't in the index, staging unstaged changes will not change eval. That said, yes, when you add a new file to a flakes repo, you start to develop…

I concur, this has not been something I've tripped up on. It's pretty obvious when it's the problem.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#52

Post by colordrops »

qbasic_forever wrote: post #14
bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…

Sorry to be blunt but I've seen nearly exact comments as yours and they come off as someone who hasn't really used Nix and doesn't understand the value proposition and the problems it solves.

I've used Ansible for years, then moved to Nix and have been on it for a year and a half. Yes the configuration language is more complex than Ansible's but it's also way more consistent and predictable. The bit of complexity comes with a lot of additional benefit. Ansible half-asses it, only giving you idempotency if you stay within certain boundaries in how you write configs. And a leaky system is a system that will break. Making it even worse is that you are building on top of a moving target with a distribution underneath that will break your Ansible scripts regularly as the system changes. Ansible is a huge mess and not suitable for the job IMHO.

With NixOS, the entire system is controlled by config, so there is only one source of truth for the state of the system, unlike Ansible. This is a fundamental flaw. Ansible is a hack on top of pre-existing setups.

With Nix, my system only gets more stable with time. It's the opposite of anything I've ever used, where systems get crufty and have to be reinstalled every couple years. Since the state of the system is fully determined by your config, you can always get to an exact state without a bunch of extra shit missing or added.

And the language isn't really that hard for anyone who's done a bit of programming. It's certainly easier than most general purpose languages, as it's static data 90% of the time with a bit of logic thrown in when needed.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#53

Post by sourcegrift »

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons:

1) There is more to learn now.

2) Split ecosystem.

I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some reason I couldn't bring myself to learn flakes ... Although that could have been because they were in limbo.

I have to say though, nix is increasingly becoming a nerd thing philosophizing over minute issues rather than "getting shit done" to benefit the maximum number of users ... :-(

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#54

Post by throwaway290 »

abathur wrote: post #20
bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

It depends on what you're hoping to get out of it. I mostly-whole-ass it, but I still use the mac app store and homebrew for a few things. Most projects are Nix by this point. It's hard to tell from how you say it; if you aren't using it for any projects and would just be using it for a slice of your system/user packages, I suspect you'll end up not really seeing what the fuss is about. If you will try to use it with…

How do you personally use Nix on a project, any tips? Do you use flakes? What are first steps/basic scaffolding? I am eager to get into Nix but not ready to go full on (I'm also on Mac but some devs may be on Linux)

Is it possible with complex projects like based on Electron? Is it reasonable to use Nix in Docker (eg. I am on Mac but want to build it like it's on CI)?

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#55

Post by pkulak »

sourcegrift wrote: post #53

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some rea…

I think we all have our own aha moments with things like this. I thought like you until I really dug in and set up Home Manager as well. My moment, and maybe this means nothing to you, was when I realized I could reference any package in a config file without even “installing” it. So it’s no longer that I have config files in Git somewhere, and then also a list of all the packages I need to install somewhere else; the config files themselves pull in the packages they need by virtue of referencing them. There are a million other things, but that’s when I was like, “Okay, I’m actually gonna do this.”

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#56

Post by biggestlou »

setheron wrote: post #50
biggestlou wrote: post #15

Earlier quoted context omitted.

Niv is fine and good but there's a lot that it will never provide, like the ability to `nix run` packages or `nix flake show` what your project provides with only a URL in hand.

You can still `nix run` packages using niv -- no clue what you talking about. You can also just look at the niv sources.json file pretty easily if you knew the URL. Rather trivial command to run. I don't find the above compelling (or correct?)

nix run github:DeterminateSystems/flake-checker

What's the Niv equivalent of this?

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#57

Post by pkulak »

sph wrote: post #40
nextos wrote: post #22

Earlier quoted context omitted.

It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it. For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibr…

I get Docker-actual reproducibility with Fedora Silverblue and toolboxes. Enter one of my Arch/Fedora containers, install Calibre without affecting the host. Even better than Nix because I can test custom distributions, rather than each environment simply being another NixOS. In fact, I've departed from vanilla Silverblue, as now my base image is an actual, bona-fide Docker container as well. I feel like the immutabl…

Yeah, Silverblue is pretty great. But Nix and Silverblue both require changes to your workflow. I like Nix more, but I don’t think one is objectively better.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#58

Post by tkz1312 »

qbasic_forever wrote: post #14
bongobingo1 wrote: post #8

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…

fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now.

https://repology.org/

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#59

Post by ibizaman »

pkulak wrote: post #55
sourcegrift wrote: post #53

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some rea…

I think we all have our own aha moments with things like this. I thought like you until I really dug in and set up Home Manager as well. My moment, and maybe this means nothing to you, was when I realized I could reference any package in a config file without even “installing” it. So it’s no longer that I have config files in Git somewhere, and then also a list of all the packages I need to install somewhere else; th…

I’m maybe missing something but non-flake nix also pull packages by just referencing them. Right?

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#60

Post by jchw »

bergkvist wrote: post #23

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…

FYI, if you want Flakes to not be tied to Git, I'd recommend using `nix [...] path://$PWD` or something along those lines. This will bypass the VCS detection for you.

Given that the Git thing is meant to stop you from shooting yourself in the foot, I think maybe it's time to conclude it wasn't really that great of an idea. However, I still see why it works that way.

Post reply on HN