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

161–170 of 186 posts

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

#161

Post by pxc »

lloeki wrote: post #86
pkulak wrote: post #13

Earlier quoted context omitted.

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?

> Honestly, it’s Home Manager that really adds the maximum value I feel like Nix does have such killer features, but they are different for everyone. For me it was: - system management (nixos + nix-darwin. I wish there was something like nix-darwin for non-nixos linux distros, binding daemon systemd units and desktop files into the "hosting" distro) - on-the-spot running without globally installing for one shot tasks…

> I wish there was something like nix-darwin for non-nixos linux distros

It's in early stages, but it exists now: https://github.com/numtide/system-manager

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

#162

Post by lillecarl »

rgoulter wrote: post #124
resonious wrote: post #116

Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like…

Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images. Sibling comment mentions that nix has ways to build NixOS VM images (e.g. https://github.com/nix-community/nixos-generato…

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones."

Never underestimate hobby usage ;)

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

#163

Post by pxc »

kbknapp wrote: post #158
tkz1312 wrote: post #58

Earlier quoted context omitted.

fwiw nixpkgs has significantly more packages than arch (including the aur), and those packages are also significantly more up to date. No other repo comes close to nixpkgs in this regard. This has been the case for quite some years now. https://repology.org/

How many of these are duplicates or just multiple versions though?

Repology already attempts to account for that, and Nixpkgs normal policy is one version per package unless there are specific reasons for it to be otherwise. Nixpkgs doesn't duplicate packages just to have alternative build options or whatever like the AUR does.

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

#164

Post by rewgs »

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…

This is a great comment. FWIW I think you'd do a great job contributing to the nix documentation.

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

#165

Post by chriswarbo »

bergkvist wrote: post #148
chriswarbo wrote: post #135

Earlier quoted context omitted.

> 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 `…

`fetchTarball` with a github archive link is much faster than `fetchGit` for bootstrapping nixpkgs.

Yes, to get Nixpkgs it's much faster to use `fetchTarball`.

You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`.

Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... )

Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )

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

#166

Post by pxc »

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.

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

I wonder what we can do about this, or what is the best way to annotate long strings in Nix code that are actually source snippets. Something like how code snippets are handled in Org files would be awesome.

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

#167

Post by pxc »

Smaug123 wrote: post #96
sourcegrift wrote: post #53

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some rea…

As a counter-anecdote, as someone who used to be a newcomer to Nix, it took until I encountered flakes before I went "aha, this is how it was always meant to be".

Do you have much development experience? I've been wondering lately whether the helpfulness or difficulty associated with flakes depends on familiarity with Nixlang and readiness to approach Nix code as code.

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

#168

Post by monka14675 »

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…

Can you tell me which one of the nix lsp servers supports the embedded configuration in multiline strings? I think neither rnix-lsp, nil or nixd support this, but maybe I am missing something.

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

#169

Post by pxc »

resonious wrote: post #116

Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like…

> but it requires fiddling with partitions by hand

Nowadays you can declare partitioning instructions with Nix just like the rest of the system: https://github.com/nix-community/disko

And you can use something like nixos-anywhere with it for a alternative process, if your provider isn't as cool as Linode and won't let you boot arbitrary ISOs: https://github.com/numtide/nixos-anywhere

Building images directly for cloud vendors' platforms on your local system and then pushing them up and assigning them to VMs is probably nicer than actually installing NixOS in the cloud, though. See this comment's siblings for that :)

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

#170

Post by pxc »

biggestlou wrote: post #126
setheron wrote: post #123

Earlier quoted context omitted.

# non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix # flake $ nix run github:fzakaria/mvn2nix#mvn2nix

mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?

The -f is for 'file', and when you point it at a directory or repo/archive path, it resolves to a default.nix file rather than a flake.nix file.
Post reply on HN