Hacker News new | ask | show | jobs
by Arnavion 1101 days ago
>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. 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.
2 comments
lillecarl 1101 days ago
It's a defined schema for exporting nix functions I'd say. I could share a flake with you to provision your disks like I do, a service like I do, your cloud infra or anything else nix can do now. It is way more than deb, but if you only compare packaging it'd be like automatically building every PPA and every locally compiled pkg against exactly your installed version of every pkg it uses.
link
pxc 1101 days ago
> > Flakes [...] facilitates the maintenance of 'out-of-tree' (read: not in Nixpkgs) Nix packages.

> Yes, aka a Nix package spec.

Right... one of things that flakes can be used to distribute is roughly comparable to an RPM spec. That is not the same thing as being an RPM spec. A BitTorrent magnet link used to distribute an MP3 file is not itself an MP3 file, either.

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

There is a sense in which flakes and RPMs can (sort of) be used to achieve the same things here, but not remotely in a way 'just like' each other. A flake.nix file is not an archive, and an RPM is not a configuration file format for something like Puppet. The latter point is so obvious that I have to assume you're being deliberately obtuse here.

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

No. RPM and DEB metapackages are 'abuses' of an archive format for either (a) just distributing install-time hooks and activating triggers or (b) forcing the installation of actual packages through the normal mechanisms of declaring dependencies on them.

Nix has no equivalent to (a) because 'installation' doesn't mean the same thing with Nix and hooks and triggers are owned by Nix profile managers rather than packages.

If Nix has anything equivalent to (b) in the RPM and DEB worlds, it's thisÂą which has nothing to do with flakes and is certainly not equivalent to a flake with no packages declared. In fact, any flake used to distribute such a buildEnv-based metapackage would have to declare it as a package.

A flake without any packages declared is not an archive of a Nix package whose data is empty but whose metadata is present.

Idk what to tell you. Clearly you are trying to somehow 'demystify' Nix terms by equating their referents to things that are familiar to you and others, but your desire for succinctness here pushes you to elide basic differences— not just with respect to Nix but with respect to source-based package management in general. Just like with two natural languages, it's simply not the case that every term here has a 1:1 translation.

--

1: https://nixos.wiki/wiki/FAQ#How_can_I_manage_software_with_n...

link