[Arnavion]

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

[pxc]

> 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 maintenance of 'out-of-tree' (read: not in Nixpkgs) Nix packages. 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.

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), and the conventions for describing the build come from there. They're not part of the flakes schema.

> Every distro package ecosystem has the maintainers discuss patches with upstream.

Again, not what flakes are about. The situation the GP is describing is where a Nix package's 'recipe' lives inside the upstream repository* and is maintained there directly by contributors to/maintainers of the upstream project. This is more like a project including a Dockerfile for the convenience of new contributors, or application developers directly publishing their own Flatpak images.

[Arnavion]

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

[lillecarl]

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.

[pxc]

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

[anotherhue]

Yes the OpenSSL one

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.