41–50 of 68 posts
This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.
Am I the only one completely confused by the examples that appear to put command line arguments after shell end-of-line comments? Is that not a typical shell? example: nix run .#cowsay -- flakes are neat Some explanation of what the heck this means would be really useful.
"--" isn't anything special in a typical shell. It's just another argument, one that customarily means "pass the rest of arguments on to a subprocess". Or are you confused about the "#"? It doesn't start a comment in the middle of a token.
Earlier quoted context omitted.
>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…
> It's a package spec, just like debian/* and rpm/*.spec. No. It's not. The interface that Nixpkgs' callPackage expects to find in default.nix within the Nixpkgs source tree is (kinda) like an RPM spec or Debian control file and friends, but that's not what flakes are. Flakes is mostly about providing mechanisms for distributing and referring to code written in the Nix language, and in that way facilitates the mainte…
Yes, aka a Nix package spec.
>But flakes can also be (and are) used to ship Nixlang libraries, end user configurations, IaC for clusters or fleets of servers, overlays of packages to be composed with an end user's copy of Nixpkgs, etc.
Yes, just like DEB / RPM packages.
>A flake doesn't have to contain any packages at all. And when it does contain a package, the package is always defined with reference to some other package collection that it pulls its dependencies from (almost always Nixpkgs)
Yes, what DEB / RPM call meta-packages.
>The situation the GP is describing is where a Nix package's 'recipe' lives inside the upstream repository
Yeah, and just like you convinced upstream to hold your Nix package spec, many upstreams hold Debian / RPM package specs too.
I would like to see composability of graphs (and other set operations on binary package repos) integrated into more dependency management systems.
FreeBSD is my server of choice and I’d love to say: create a package repo with my config package and it’s dependencies and nothing more and deploy from that knowing a million other dependencies can’t be pulled in (e.g. give me a new jail that pulls from subset).
It’s probably something I should prototype one day.
Earlier quoted context omitted.
> It's a package spec, just like debian/* and rpm/*.spec. No. It's not. The interface that Nixpkgs' callPackage expects to find in default.nix within the Nixpkgs source tree is (kinda) like an RPM spec or Debian control file and friends, but that's not what flakes are. Flakes is mostly about providing mechanisms for distributing and referring to code written in the Nix language, and in that way facilitates the mainte…
>Flakes [...] facilitates the maintenance of 'out-of-tree' (read: not in Nixpkgs) Nix packages. Yes, aka a Nix package spec. >But flakes can also be (and are) used to ship Nixlang libraries, end user configurations, IaC for clusters or fleets of servers, overlays of packages to be composed with an end user's copy of Nixpkgs, etc. Yes, just like DEB / RPM packages. >A flake doesn't have to contain any packages at all.…
I’m surprised all of these systems combine build logic and dependency graphs in the same config. It seems like flake might be a step in understanding these things are only tangentially related. I would like to see composability of graphs (and other set operations on binary package repos) integrated into more dependency management systems. FreeBSD is my server of choice and I’d love to say: create a package repo with…
The system you describe building is exactly what nix does, as well as debian, El, and Arch. Their spec files describe both build and runtime dependices, and installing the package does not install things like Make.
Nix goes a little bit further by only including runtime dependices that it can find it the build output. It does this by scanning the output files.
But I don't understand how you could separate build graph and runtime graph. If I declare something needs foo and bar, that is useless unless I can get built foo and bar. _Something_ has to know how to build the things this hypothetical system is installing.
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.
That’s my experience using Nix in a nutshell, every time I’ve tried 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!
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`.
You might have two dozen flakes in your system. You'll typically only have a single channel, if you use them.
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.
So...devbox adopted flakes before Nix did? lol.
It's not for everyone, but when you work with infrastructure and can guarantee that the software the developers build is the exact same version you're running for them it feels good to have that conversation out of the way already.
But also, my "personal config" has two dozen imports and overrides nixpkgs on most of those. I have a list of complaints regarding flakes that is only dwarfed by 6+ year old general nix issues, but I could never go back.