Why did Nix adopt Flakes?
jetpack.io
Why did Nix adopt Flakes?
1–10 of 68 posts
Re: Why did Nix adopt Flakes?
#2This is a bit of a unnecessarily provocative title, since the question of whether or not to promote the 'experimental' flakes system and replace the channels mechanism is still an active and controversial one in the Nix community. There hasn't been any significant news on this front recently; this article simply explains why flakes were introduced as an experimental feature.
Re: Why did Nix adopt Flakes?
#3This is a bit of a unnecessarily provocative title, since the question of whether or not to promote the 'experimental' flakes system and replace the channels mechanism is still an active and controversial one in the Nix community. There hasn't been any significant news on this front recently; this article simply explains why flakes were introduced as an experimental feature.
Oh, it isn't intended to be provocative.
The title is simply literally the question that I was thinking about a few months ago when working on Devbox, and wrote a version of this post internally to answer the question for myself!
Re: Why did Nix adopt Flakes?
#4I'm a casual nixpkgs contributor. Flakes are like the embassies Nix sends out into the OSS world. Discussion about building the application are kept with the application, nuances and patches can be discussed with the actual authors.
Remember the debian SSH packaging snafu? The application authors weren't involved. (edit: see below)
Nixpkgs is like the state department, a central unifying hub, great to bootstrap the package ecosystem (ten years old now), but it needs to spread its wings.
Re: Why did Nix adopt Flakes?
#5This is a bit of a unnecessarily provocative title, since the question of whether or not to promote the 'experimental' flakes system and replace the channels mechanism is still an active and controversial one in the Nix community. There hasn't been any significant news on this front recently; this article simply explains why flakes were introduced as an experimental feature.
I'm curious what you would change the title to so that you perceive it to be less provocative? In my (disclosure: not engaged in the community much at all) opinion the provocation here is simply because the topic touches on a controversial issue.
Re: Why did Nix adopt Flakes?
#6My biggest issue with Nix flakes right now is the way it integrates with Git.
It insists on copying the entire repository into the Nix store (which makes all of its content world-readable!). Even if your flake.nix is in a subdirectory of a monorepo, the entire monorepo will be copied into the store every time!
Re: Why did Nix adopt Flakes?
#7This is a bit of a unnecessarily provocative title, since the question of whether or not to promote the 'experimental' flakes system and replace the channels mechanism is still an active and controversial one in the Nix community. There hasn't been any significant news on this front recently; this article simply explains why flakes were introduced as an experimental feature.
Oh, it isn't intended to be provocative. The title is simply literally the question that I was thinking about a few months ago when working on Devbox, and wrote a version of this post internally to answer the question for myself!
Ah, that's good to know :) It is just that I was expecting to read about some breaking news; that I missed that Nix deprecated channels or something! It is indeed a nice article explaining Flakes in general. Maybe "Why did Nix introduce Flakes?" might be a slightly better title for people coming with prior expectations like I did?
Re: Why did Nix adopt Flakes?
#8I'm a casual nixpkgs contributor. Flakes are like the embassies Nix sends out into the OSS world. Discussion about building the application are kept with the application, nuances and patches can be discussed with the actual authors. Remember the debian SSH packaging snafu? The application authors weren't involved. (edit: see below) Nixpkgs is like the state department, a central unifying hub, great to bootstrap the p…
>Flakes are like the embassies Nix sends out into the OSS world.
It's a package spec, just like debian/* and rpm/*.spec.
>Discussion about building the application are kept with the application, nuances and patches can be discussed with the actual authors.
Every distro package ecosystem has the maintainers discuss patches with upstream.
>Remember the debian SSH packaging snafu? The application authors weren't involved.
Assuming you're referring to the 2006-2008 OpenSSL vulnerability (which affected openssh and other things), yes the openssl devs were involved. The Debian maintainer who added the bad patch asked about it on the openssl mailing list, and only added it after he got ACKs from the devs.
Re: Why did Nix adopt Flakes?
#9Earlier quoted context omitted.
Oh, it isn't intended to be provocative. The title is simply literally the question that I was thinking about a few months ago when working on Devbox, and wrote a version of this post internally to answer the question for myself!
Ah, that's good to know :) It is just that I was expecting to read about some breaking news; that I missed that Nix deprecated channels or something! It is indeed a nice article explaining Flakes in general. Maybe "Why did Nix introduce Flakes?" might be a slightly better title for people coming with prior expectations like I did?
s/adopt/introduce
done :)
Re: Why did Nix adopt Flakes?
#10My biggest issue with Nix flakes right now is the way it integrates with Git. It insists on copying the entire repository into the Nix store (which makes all of its content world-readable!). Even if your flake.nix is in a subdirectory of a monorepo, the entire monorepo will be copied into the store every time!
Isn't it the same with channels though? On my system `/nix/var/nix/profiles/per-user/root/channels/nixos` is a symlink to `/nix/store/[...]-nixos-23.05/nixos`.