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

151–160 of 186 posts

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

#151

Post by yencabulator »

ParetoOptimal wrote: post #129
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. You only need to `git add` the file once. You do not need to stage every change after that before flakes can "see" the change.

Even better, you can `git add -N` and just record the intent to include the file in a later commit, without staging its current contents. Nix seems happy with that.

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

#152

Post by gallexme »

RaitoBezarius wrote: post #17
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?

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.

Pretty sure nix flake check --all-systems Builds it for all systems, u just have to add a check for the package

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

#153

Post by yencabulator »

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…

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

That's what flake.lock is for, it remembers the versions picked. No need to put versions in the flake urls just for that.

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

#154

Post by midchildan »

Filligree wrote: post #36
qbasic_forever wrote: post #26

Earlier quoted context omitted.

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…

Nix doesn't do network, PID or filesystem isolation. That's a feature. I don't normally want any of those.

My thoughts exactly. Container-based development environments has a Cygwin-like clunkiness to it. But even clunkier because of the default lack of access to the host system, and the additional burden of having to manage multiple containers.

Just to be clear, Cygwin is a great project. But it's not something I'd actively choose over a native Linux system if I had the choice of operating systems.

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

#155

Post by lillecarl »

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.

Just because you can't grasp the benefits doesn't mean they're not there, in reality it solves all in-user config for a lot of people using it.

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

#156

Post by pxc »

bergkvist wrote: post #146
ParetoOptimal wrote: post #129

Earlier quoted context omitted.

> Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. You only need to `git add` the file once. You do not need to stage every change after that before flakes can "see" the change.

Yes, you are right - I misremembered this detail. My problem at the the time was I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons). So I had to unstage and restage it every time I created a new commit.

> I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons).

Does the same workplace not allow people to include config related to their editors and so on?

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

#157

Post by pxc »

pmarreck wrote: post #136
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. B…

If you don't lose the whole repo, you can probably pull those versions of of the git reflog even if you do lose them. One of the blessings of having `git add`ed something.

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

#158

Post by kbknapp »

tkz1312 wrote: post #58
qbasic_forever wrote: post #14

Earlier quoted context omitted.

It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…

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?

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

#159

Post by qbasic_forever »

kaba0 wrote: post #141
qbasic_forever wrote: post #139

Earlier quoted context omitted.

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.

Loading in the whole container though does increase the necessary RAM — with nix, two versions of the same executable can link to the same hash, but it is unlikely to be the case with Docker.

Your kernel is fine at managing the container root filesystem and paging in and out parts as necessary. It's not just loading gigabytes of root fs into memory and calling it good.

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

#160

Post by pxc »

seabass-labrax wrote: post #150
pmarreck wrote: post #138

Earlier quoted context omitted.

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

It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be helpful for completely architecture-less packages (such as interpreted scripts).

Which deps they pull in is still determined by system because their interpreters are in the dependency closure and what arch Perl is built for affects that Perl package's hash, etc.
Post reply on HN