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

41–50 of 186 posts

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

#41

Post by jfoutz »

nextos wrote: post #22
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 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'm new to nix/nixos but gradually building up my environment.

it's like having your whole OS in git. it's amazing. want to try out some nightly build? no problem.

on most computers (personal, home computers) the various lib dirs get scary after a while. repoquery can help, but is kind of a hassle. if some executable `foo` depends on some specific behavior in some version of some library, it's fine. that weird library can stay in place, I can try out nightly's of foo, can always rollback to the system that used to work, and can flip to the new foo when it's ready.

I think it's a good practice to wipe and re provision from time to time to make sure provisioning and backups actually work, but like, you can screw around with _crazy_ things and not really have to worry about having to rebuild the whole thing. (well, I haven't yet) I still will, because that's how I am. but I can do it when I feel like it, not when I fucked up. it's so easy to un fuck a nix system.

I guess the big caveat is, this is a hobby. I haven't used nix for work. Back in the day, I did support docker in production when the kernel patches were coming pretty quickly. Finding the right balance of patch level, and libc version, that would support docker, and the other stuff that needed to run was a pretty complicated dance, and missing a step would be, not great. Knowing what I know now, even as a hobbyist, I probably could have made my life a lot easier back then.

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

#42

Post by predictabl3 »

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 a habit of always adding it to the stage/index for eval.

but you should ONLY ever see this as a very very obvious "file not found", it is not a subtle problem as this post implies.

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

#43

Post by predictabl3 »

RaitoBezarius wrote: post #17
m1keil wrote: post #4

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?

For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use. Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback. This whole debacle made a lot of invested people tired on both sides.

> Flakes have no concept of cross compilation and makes this use case extremely tedious to use.

I don't agree at all. I use flakes with cross compilation literally all of the time. Having a concept of "cross-compilation" at the CLI level, instead of being part of the nix evaluation itself would be a travesty IMO. I love being able to do a single nix eval that includes 3 different architecture of native builds for my host toplevels, along with "cross" variants that set hostPlatform to x86 and produce cross-builds.

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

#44

Post by predictabl3 »

setheron wrote: post #3

I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability. I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)

Except that niv doesn't ensure pure evaluation, and thus a number of non-flakes, niv-friendly projects are unusable with flakes, and are often difficult to work with otherwise due to their impurities.

It also can't do transient overrides which is quite literally the essential reason that Flakes is killer to me.

For example, I can cross-compile to riscv64-linux, including a bunch of 3rd party flakes repos *specifically* because I refer to them and then override their nixpkgs to point to my nixpkgs with various cross-compilation fixes.

Definitely not possible to do this with niv.

It also does nothing to solve the countless issues with channels that I've watched afflict countless new Nix users, every week, for 3+ years. [insert the usual 8-stop troubleshoot list when a user has any issue possibly related to channels]

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

#45

Post by bongobingo1 »

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…

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity

I think this is where most of the "i went back" posts I read came from. That and hitting issues with programs that expect to be able to write to some XDG dirs.

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

#46

Post by packetlost »

_hl_ wrote: post #37
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…

> Building third party flakes takes forever since every flake uses its own version of nixpkgs. The “official” (as in, community consensus) solution seems to be to bring your own nixpkgs, and manually override the nixpkgs of every dependency (and their transitive dendencies) and verify your build still works. Which just doesn’t seem right to me. Flakes are great for building an ecosystem of composable, reproducable so…

The traditional way is to reduce the surface area of the core package as much as possible, such that it sees less changes/releases overall.

The way I would do it with nix is: because everything gets hashed, just check that the built output with a new nix-pkg version matches the hash with the old version and fail out/fetch the older version as a second step. The rest is just finding ways to cache that build fail information so that you can share the result across users transparently.

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

#47

Post by 40yearoldman »

RaitoBezarius wrote: post #17
m1keil wrote: post #4

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?

For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use. Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback. This whole debacle made a lot of invested people tired on both sides.

What? I compile my arm64 system on a amd64 system and send them to my cache server so my arm systems don’t have to do the work and just download the outputs and apply them.

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

#48

Post by jsomedon »

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…

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity as you now need to fully understand the nix language and its concepts like derivations. This isn't necessarily hard but it is not documented well at all, and there are factions in nix at odds with each other (flakes vs. nix-env) which make learning it even more confusing.

Exactly this was why I am so hesitant to switch to nix. I tried to dig into the details of nix, language, derivation and whatnot, but documentations and community discussions are, in my experience pretty segregated that left me confused, and I eventually went back to arch.

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

#49

Post by setheron »

predictabl3 wrote: post #44
setheron wrote: post #3

I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability. I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)

Except that niv doesn't ensure pure evaluation, and thus a number of non-flakes, niv-friendly projects are unusable with flakes, and are often difficult to work with otherwise due to their impurities. It also can't do transient overrides which is quite literally the essential reason that Flakes is killer to me. For example, I can cross-compile to riscv64-linux, including a bunch of 3rd party flakes repos *specificall…

I tend to just override nixpkgs downstream. I think the situation you are describing is more power-user.

Flakes to me introduced a lot of overhead beyond what niv can provide.

I get 99% value just pinning my top level dependencies since most of the time I'm referring nixpkgs + 1-2 other packages.

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

#50

Post by setheron »

biggestlou wrote: post #15
setheron wrote: post #3

I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability. I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)

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

Post reply on HN