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

61–70 of 186 posts

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

#61

Post by pkulak »

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…

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.

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

#62

Post by seabass-labrax »

40yearoldman wrote: post #47
RaitoBezarius wrote: post #17

Earlier quoted context omitted.

For example, Flakes have no concept of cross compilation and makes this use case extremely tedious to use. Flakes were a RFC then merged as an experimental feature and shilled too much to the community to the point they are now a quasi standardized feature even though they didn't go through RFC and therefore ignored all the valuable feedback. This whole debacle made a lot of invested people tired on both sides.

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 Nix derivations over and install them temporarily with nix-shell. Thanks for the inspiration!

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

#63

Post by Cloudef »

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…

You can do everything without flakes as well by using fetchTarball, fetchGit etc, with shasums, but flakes just improves the ergonomics. Because of the lock files, flakes are also faster, especially nice if you use nix develop (the new nix-shell alt)

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

#64

Post by rgoulter »

ibizaman wrote: post #59
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 maybe missing something but non-flake nix also pull packages by just referencing them. Right?

Yes, in Nix code it is possible to refer to arbitrary Nix codebases from Nix code.

I'd point to the home-manager installation instructions for an example of Nix flakes having a nicer UX. Running flake-enabled codebases is just much nicer than non-flake codebases.

https://nix-community.github.io/home-manager/index.html#sec-...

https://nix-community.github.io/home-manager/index.html#sec-...

The former involves running `nix-channel --add home-manager && nix-channel --update` in order for `` to mean anything. With the latter, it's simply `nix run home-manager/release-23.05 -- init --switch`. (Albeit, `home-manager` is already registered as an alias for `github:nix-community/home-manager`).

One key detail is that `nix-channel --add` modifies the 'system state', whereas running flakes essentially does not.

-- Regarding "you can pull in arbitrary Nix code by reference". With flakes, you have a standard entry point where you know the interface it has. Whereas, having a 'default.nix' is a convention, and there's no way to know how a `default.nix` is to be used without reading its source.

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

#66

Post by eternityforest »

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…

It's kind of scary because Nix is one of the coolest concepts for how to manage Linux systems... Most everything else has so much baggage from things that were designed around hand-maintained, non-disposable installs.

But the community does seem to be still tinkering focused.

I miss the early 2000s when even the hackers seemed to want to make their stuff easy to use(although my source for that is I saw a screenshot of low orbit ion cannon one time, I don't actually know much about hacker history).

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

#67

Post by rrix2 »

jchw wrote: post #60
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…

FYI, if you want Flakes to not be tied to Git, I'd recommend using `nix [...] path://$PWD` or something along those lines. This will bypass the VCS detection for you. Given that the Git thing is meant to stop you from shooting yourself in the foot, I think maybe it's time to conclude it wasn't really that great of an idea. However, I still see why it works that way.

This makes the third issue of the parent comment much worse, unfortunately since there will be a new /nix/store hash when even things in .gitignore or things like lock files or editor backup files are touched. I've cleaned up hundreds of gigs after a long evening of hacking

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

#68

Post by toastal »

wtetzner wrote: post #25
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…

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

The biggest advantage is the ability to reproduce your mutable environment‽ You get more advantages when the whole environment is reproducible.

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

#69

Post by sourcegrift »

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

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.

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

#70

Post by rgoulter »

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…

> Not only do most users gain very, very little from it

How do you come to that conclusion?

Those who switch to using flakes are enthusiastic about the improved UX.

> flakes is that it is too much added complexity for tiny incremental gains

A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project.

The benefits are hard to get otherwise.

With flakes, `flake.nix` provides a standard entrypoint to a Nix codebase. Without flakes, you might see a `default.nix`, but would have to read the `default.nix` to know how it's supposed to be called.

With flakes, the exact version of Nixpkgs used is locked. Without flakes, I'm not aware of an easy way to do this with channels; and there are a variety of ways (read: no standard way) to do this in Nix code.

Post reply on HN