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

131–140 of 186 posts

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

#131

Post by zamalek »

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 am forced to run both, work needs Intune which needs Ubuntu (I'd use NixOS everywhere if I could). Here is my config, but be warned it'll probably confuse a newcomer: http://codeberg.org/jcdickinson/nix

My config/flake is cleaved in two: one for NixOS (which isn't used for Ubuntu) and one for "Generic Linux" (which is used everywhere). I used to have nix-darwin in there too, but Intune on Ubuntu has allowed me to retire the work Mac.

The second-half is where the real value lies (my NixOS config is actually really minimal, just enough to get into sway). I use home-manager to manage all my dotfiles. I switched work laptops recently and nix+home-manager brought up the environment in less time than it took to install Ubuntu - and that's a full desktop replica (Gnome plugins, hotkeys, installed apps, nvim config, and everything).

The next big benefit is direnv integration. Direnv itself is bloody fantastic, but add nix to the mix and you have a whole new level of magic. If there is an in-tree flake I can just echo `use flake` to establish a dev environment with all dependencies, at the right version, through the mere act of cd'ing into that dir. If there's no in-tree flake (as is the case with my work repos), I can use one of my dev-shells with e.g. `use flake $HOME/Nix#cmg-js` (assuming I've cloned my config to ~/Nix).

There's no real reason for me to use NixOS on my own machine, but I do love the boot speed and the ability to roll back. I'm pretty fearless when changing my OS config. The nature of Nix means very little beyond what you explicitly demand is installed, and it keeps snapshots of your previous configs. It's not mandatory at all, though. Home-manager is where it shines.

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

#132

Post by chriswarbo »

sourcegrift wrote: post #69
pkulak wrote: post #55

Earlier quoted context omitted.

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 familiar with home manager (or as I like to call it, a hammer looking for a nail, that solves no problem). I don't think home manager has any relationship with flakes. Also, nix solves actual real problems, home manager doesn't. There are better dotfile managers. In fact, vim understands the syntaxes of a lot of dotfiles, with home manager, you even lose that.

> In fact, vim understands the syntaxes of a lot of dotfiles, with home manager, you even lose that.

Nix is perfectly capable of referencing external text files (e.g. `./my-config-file.ini`), which you can write with vim or whatever if you like.

It's trivial to put such files in place with Home Manager (or NixOS config) if you want, e.g.

  home.file.foo.source = ./my-config-file.ini;
Home Manager is certainly overkill if that's all you're using it for; but many more things become possible thanks to its use of Nix. For example, you can run some find/replace on the file contents (say, to splice in some Nix store paths, or the results of some calculation); you can fetch arbitrary files from arbitrary locations (e.g. some other git repo); you can choose between alternative contents based on arbitrary criteria (say, CPU type, or hostname); etc.

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

#133

Post by chriswarbo »

sourcegrift wrote: post #101
colordrops wrote: post #76

Earlier quoted context omitted.

There are Nix LSP servers now that handle embedded config files. But beyond that, you can always just leave the config in its original format and import it into the Nix config, and not lose your syntax highlighting. Speaking of vim, I've got neovim configured completely with home manager. It references plugins as first-class nix packages, and also any external dependencies like language servers, node packages, parsin…

But I have the exact same setup without the "hammer-searching-for-nail" home manager. (Almost) all of my vim plugins are managed by my nixos config

Home Manager is less useful if you're using NixOS. I've found it handy on non-NixOS systems, e.g. my phone; although I'm planning to switch that to NixOS at some point too ;)

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

#134

Post by chriswarbo »

sullyj3 wrote: post #81
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'm running home-manager on arch and it's fantastic. I'm only using it for cli/tui programs, as I've had trouble getting gui software to correctly create desktop entries which show up in my menus. You can use it alongside pacman just fine.

These options got GUI icons to appear for me (on Manjaro, an Arch derivative):

  targets.genericLinux.enable = true;
  xdg.mime.enable = true;
  xdg.systemDirs.data =
    [ "${config.home.homeDirectory}/.nix-profile/share/applications" ];

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

#135

Post by chriswarbo »

nextos wrote: post #6
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?

Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when u…

> However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels.

I'm still not convinced by flakes; however, I agree that channels are problematic (and I still don't fully understand them, after a decade!). The first things I do after installing Nix are to delete all the channels and unset `NIX_PATH`. I used to use `` for bootstrapping via `fetchgit`, but even that's unnecessary now that `fetchGit` is part of `builtins` :)

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

#136

Post by pmarreck »

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 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.

There's an upside to this: I've been in situations where I've lost the definition of a previous configuration because I didn't check the state of it at that point into source control. By "forcing" the user (me) to at least add the current state to source control (if not commit it), it makes it more likely for me to have the configuration/definition for the state saved at the same time as the state itself.

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

#137

Post by pkulak »

sourcegrift wrote: post #69
pkulak wrote: post #55

Earlier quoted context omitted.

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 familiar with home manager (or as I like to call it, a hammer looking for a nail, that solves no problem). I don't think home manager has any relationship with flakes. Also, nix solves actual real problems, home manager doesn't. There are better dotfile managers. In fact, vim understands the syntaxes of a lot of dotfiles, with home manager, you even lose that.

I moved from Chezmoi to Home Manager. Chezmoi is easily the best dotfile manager I had used at the time, and Home Manager is on a totally different level.

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

#138

Post by pmarreck »

hlandau wrote: post #105

To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake util…

> they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous

Well, we're talking about evaluating a pure function (literally the entire philosophy of Nix is treating a build like a pure function). Those things are variable state as an input which affects the output, and therefore must be specified as inputs. I don't see the problem here (if you have already accepted that you want to treat builds as pure functions with total encapsulation of the state required to run them, and thus having deterministic outcomes).

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

#139

Post by qbasic_forever »

kaba0 wrote: post #94
pkulak wrote: post #61

Earlier quoted context omitted.

It’s a lot lighter in terms of disk space. Yes, drives are cheap, but even so, bringing in a different version of debian-slim for every executable gets bloaty. I routinely reclaim 10s (sometimes 100s) of gigs with a podman system reset.

Also in RAM. You don’t want to runa whole-ass container for `ls`.

No a process running in docker or on your host is going to use the same amount of RAM. There is no RAM dedicated to a running container on Linux--it's just a process that's flagged with some metadata to tell the kernel that it should be isolated in certain ways, like with a unique root filesystem.

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

#140

Post by 40yearoldman »

seabass-labrax wrote: post #62
40yearoldman wrote: post #47

Earlier quoted context omitted.

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.

That's something I would like to try for my PinePhone. It's been tedious to do development for it, as the PinePhone's CPU struggles with most compilation tasks. Using Nix would be a good way of building for that platform's somewhat exotic features (arm64 and musl libc) on a more powerful machine, without confusing the system package manager with package versions outside the distribution - I should be able to copy the…

Make sure you use copy-closure and target the result directory. My fist attempts had some crazy find script copying all of nix-store with copy-closure. You can skip this part if you make the build machine the same as the cache machine as the results are automatically cached.
Post reply on HN