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

31–40 of 186 posts

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

#31

Post by tiffanyg »

pkulak wrote: post #13
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…

I don’t know the value of half-assing it, but committing your full ass is amazing. Don’t abandon a working system, but the next time you wait a whole three weeks to pacman -syu and your GPG keys are out of date and everything goes to hell… give it a shot. Honestly, it’s Home Manager that really adds the maximum value, and getting all the way there takes a full weekend, but what were you gonna do anyway?

I don’t know the value of half-assing it, but committing your full ass is amazing.

Indeed. As no less than Ron Swanson rendered unto us - an exemplar in classic American yarn form:

https://youtu.be/k6hZ9KdG1QU

... wise words.

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

#32

Post by pxc »

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…

This is good constructive criticism and I'd like to second every part of it.

You're probably already aware, but for the benefit of newcomers in this thread, here's a link to the massive PR trying to work out more efficient copying of local flakes to the Nix store:

https://github.com/NixOS/nix/pull/6530

A few dedicated folks are working really hard to break that thing down and test it and get it merged. I can hardly wait!

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

#33

Post by bergkvist »

CuriousCosmic wrote: post #30
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…

> Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. Could you not just do a sparse checkout for monorepos? https://github.com/NixOS/nixpkgs/pull/135881

My use case here is not using pkgs.fetchgit etc - but rather when developing a package locally and rebuilding it.

Let's say I'm working on a huge monorepo locally, with GBs of code and data in it, most of which I want to ignore in my nix build. Let's say the files I actually care about are also not in a single subfolder. Then I can't just move the flake.nix to that subfolder either.

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

#34

Post by yjftsjthsd-h »

EE84M3i wrote: post #29

Can someone that understands this "limbo" and "long standing tensions" give a TL;DR for someone that knows what flakes and the new cli are but hasn't been following the community discussions around it?

Flakes are amazing but have been designated as an unstable or beta feature for I think literally years now, which creates tension between the desire to get them polished and perfect and the desire to have them be the one true official way to do things already.

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

#35

Post by CuriousCosmic »

bergkvist wrote: post #33
CuriousCosmic wrote: post #30

Earlier quoted context omitted.

> Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. Could you not just do a sparse checkout for monorepos? https://github.com/NixOS/nixpkgs/pull/135881

My use case here is not using pkgs.fetchgit etc - but rather when developing a package locally and rebuilding it. Let's say I'm working on a huge monorepo locally, with GBs of code and data in it, most of which I want to ignore in my nix build. Let's say the files I actually care about are also not in a single subfolder. Then I can't just move the flake.nix to that subfolder either.

Oh yeah in that case it'd be a problem. There might be a way around that but that case definitely isn't ideal. albeit you could probably sparse-checkout your repo to avoid that if you don't need all of it.

definitely not ideal and I agree that until lazy file mapping, content addressed derivations, and file deduplication get implemented that the UX will be rough in some cases.

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

#36

Post by Filligree »

qbasic_forever wrote: post #26
wtetzner wrote: post #25

Earlier quoted context omitted.

> Do you get anything when not using NixOS to manage everything? Sure, I think the biggest benefit is being able to get a temporary environment for a project. You can have all of your dependencies pinned, even for languages that don't have package managers, and for mixed-language projects. You can get easily get a shell that contains the exact compiler versions, libraries, etc. from a single config file, and it's iso…

It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc. With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store direct…

Nix doesn't do network, PID or filesystem isolation.

That's a feature. I don't normally want any of those.

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

#37

Post by _hl_ »

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 software. The more they succeed at that, the bigger the problem becomes. Surely it’s not too late to figure out a principled solution before stabilizing flakes?

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

#38

Post by pxc »

It feels really good to see this RFC cross the finish line into a finalized plan.

The plan itself seems very well thought out. I had a vague desire for an incremental stabilization of flakes some time ago, but this is so much better.

The flakes divide is one of the biggest remaining problemd facing the community, now that the issues with the release cycle have improved so much and continue to improve. Each step taken in executing this plan will be a real boon for the Nix community.

Onward!

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

#39

Post by qbasic_forever »

Filligree wrote: post #36
qbasic_forever wrote: post #26

Earlier quoted context omitted.

It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc. With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store direct…

Nix doesn't do network, PID or filesystem isolation. That's a feature. I don't normally want any of those.

You don't have to use them, docker has flags to disable things like network isolation. If you want to go deeper systemd-nspawn doesn't isolate anything (network, pid, user, etc.). And if you are some anti-systemd zealot the plain old chroot command does what you want too (and has done so for decades).

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

#40

Post by sph »

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 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 immutable Linux OS is the pragmatic approach, whereas NixOS is the pure, ideal way that requires a lot of changes to tools and workflow to work. Maybe even in this case, worse is better.

Post reply on HN