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

101–110 of 186 posts

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

#101

Post by sourcegrift »

colordrops wrote: post #76
sourcegrift wrote: post #69

Earlier quoted context omitted.

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.

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

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

#102

Post by mongol »

lloeki wrote: post #99
duped wrote: post #71

I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.

> without double checking It's fine, Nix things are conceptually different from anything before. You could say flakes are like Rakefile, but that would be a lie. You could say they're like Gemfile and Gemfile.lock, but that would be a lie too. You could say that derivations are like packages, but that would be a lie, you could say they're like container images but that would be a lie too. Now, you can try to understa…

> If you look at an actual (snow)flake there's this recursive/fractal design coming from a central point, which kind of visually represent the conceptual structure underpinning a nix flake

Never thought about it that way, but it kind of makes sense. I thought the name was inspired by the Nix logo.

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

#103

Post by gallexme »

Love nix and flakes, can easily describe my whole infrastructure in nix(even generating terraform files from it, manage secrets(agenix,agenix-rekey), and dev tools required to work on parts of the infrastructure(LSP's, deploy-rs, secrets decrypting using ssh key,rekeying secrets to public keys of machines), all in one flake, one monorepo (virtually split up with the josh project into multiple repos with shared history,works really well)

I love it, only thing I would love if there was a proper way for passing arguments to flakes for build /dev/run only dependencies and other ways to specialize the scope of the user using the flake and infrastructure attached to it :)

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

#105

Post by hlandau »

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

Having to rely on an unendorsed third party just to write architecture-independent code isn't very appealing to me. This seems like a serious deficiency in the design of Flakes, though it would be tolerable at least if this functionality was at least in Nixpkgs.

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

#106

Post by lemper »

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

then what's the point of using nix and flakes if flakes destroy the very point of nix, reproducibility?

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

#107

Post by starlevel003 »

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?

> but what were you gonna do anyway?

go outside, talk to friends, do something productive, etc...

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

#108

Post by teekert »

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.

So very package should be a system package, available to every user?

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

#109

Post by teekert »

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

Which you can presumably only do on a 1 user system right? (I’m just trying to understand, I thought home manager makes more sense on a multi user system, and has some options for more fine grained configuration?

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

#110

Post by bergkvist »

duped wrote: post #71

I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.

A derivation is simply an attrset with `type = "derivation"` as a key-value pair in it
Post reply on HN