11–20 of 68 posts
My 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!
https://github.com/jetpack-io/devbox/blob/main/internal/impl...
I'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…
I think this is a great strength of flakes. Packaging an application can sometimes have nuances that external folks may not be fully aware of and so having the packaging instructions (i.e. flake.nix) defined in the core repository can narrow that knowledge gap.
Earlier quoted context omitted.
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 :)
I'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 involve…
https://lists.debian.org/debian-security-announce/2008/msg00...
> he got ACKs from the devs
You're totally right: https://news.ycombinator.com/item?id=6343782
> Every distro package ecosystem has the maintainers discuss patches with upstream.
I don't think that's entirely fair to say, it's certainly best practice.
My 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!
My 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!
It's a known issue but fortunately is being worked on: https://github.com/NixOS/nix/pull/6530
So, did Nix actually adopt flakes ? Because last time I checked, it was still an experimental feature that everyone insists on using, but… it's still experimental, which means you have to make effort to use it.
Flakes, home manager, half the packages I need, etc
My 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!
So, did Nix actually adopt flakes ? Because last time I checked, it was still an experimental feature that everyone insists on using, but… it's still experimental, which means you have to make effort to use it.