Fantastic! Happy flake user here who will be pleased to have the documentation updated and referring to the workflows we use.
NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
21–30 of 186 posts
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#22Ive 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#calibre.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#23The 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 than I'd like to admit wondering why what I'm building doesn't include my latest change.
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.
This kind of copying would likely be a lot more acceptable if it was specified explicitly in flake.nix, rather than implicitly. Then you could also use your own filters for ignoring files, rather than relying on the coupling to git and its staging area.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#24NixOS is honestly so beautiful and rare. I'm delighted that the project is moving forward in this way.
A friend of mine called it a "rabbit hole" but TBH it's words of power -- I can speak new instances of my environment into existence, not only on newly-acquired compute devices, but on other OSes as well (I put some effort into segmenting the user environment and system config between home-manager and standard /etc/nixos/*)
Nix flakes will only make me more powerful
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#25Ive 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…
> 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 isolated from the rest of the system. I guess it's kind of like having a lighter-weight container.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#26Ive 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…
> 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 directory--the process you run is exactly the same as whatever you're running in docker.
One crucial difference is that nix does nothing for network isolation, you have to do all that on your own (if you need it).
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#27Earlier quoted context omitted.
I use nix with flakes, have written a couple of flakes day to day use. I am not a nix power user. But based on my current understanding this statement seems incorrect > Flakes are tightly coupled to Git. How is it tightly coupled to Git if it supports Mercurial out of the box? Other than using version control to determine what are the sources of the derivation, what does flakes lean on version control?
I meant this kind of issue: https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-...
That is what I was trying to say by
> Other than using version control to determine what are the sources of the derivation
I don't think that defaulting to using git to list the sources when inside a git repo means that it is tightly coupled to git. If one doesn't want to commit/stage the flake files in the repo one can do `nix develop .` and it works . It will take a little longer because it will copy the entire directory to the store iiuc.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#28Ive 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…
> Do you get anything when not using NixOS to manage everything? [...] Has anyone gone down this route?
Yeah, for sure! I don't use Nix this way very much on Linux because I mostly just use NixOS. But I use Nix this way on macOS at work every day, because that's the Unix desktop that's available to engineers there.
By not going full NixOS, the tradeoff is that you suffer some minor integration issues, and in return you get some more escape hatches. This is a pretty good option for some people imo.
Declarative system config on non-NixOS is a bit more work, because you either have to write your own sort of metapackages with buildEnv¹ or use a third-party module system like Home Manager, System Manager (that one's in very early stages, so pronably skip it if you're a newbie), or Nix-Darwin. The latter are really nice, but you might have to think about how they plug into things like your OS's bashrc file sometimes, and sometimes their install procedures are kinda wonky.
The other main integration quirk to watch out for on non-NixOS is 3D graphics acceleration. Check out nixGL and you'll be covered for that.
Using Nix for nifty per-project development environments, though, is pretty smooth and basically identical whether you're on NixOS or not. If that's an interesting use case for you, Nix on non-NixOS is worth checking out.
Nix as a package manager for CLI tools that don't depend on the base system, or trying out software without permanently installing it, is also kinda nice on other distros. It's especially nice for running newer software on top of stale distros, but it can also take you in the other direction, which might sometimes be useful on Arch.
I think the head first approach of just committing to daily driving NixOS can be good for some people, and it certainly was for me. But learning your way around the Nix language and developer tools by focusing on developer environments and oddball packages on a foreign OS can definitely make for an easier, lower stakes learning process.
> What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix?
If you're not using Nix for any per-project stuff, you're definitely missing some value, as that's likely among the first low-hanging fruit you'll encounter on your Nix journey.
That said, stacking Nix with other package managers and only using it where it makes most sense is totally viable. On macOS, I use it in combination with light use of pkgsrc and Homebrew. You can definitely do the same kind of thing on Linux.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#29Can 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?
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#30The 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?