7 ms·

Why did Nix adopt Flakes?

seabass-labrax 3y ago
This 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.
- pushtheenvelope 3y ago
  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!
  - seabass-labrax 3y ago
    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?
    - pushtheenvelope 3y ago
      s/adopt/introduce done :)
      - seabass-labrax 3y ago
        Thank you; that was quick! :) I apologise if my original comment came across as rather harsh!
        pushtheenvelope 3y ago
        idk, someone (moderator?) changed it back ...
- toolz 3y ago
  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.
  - rgoulter 3y ago
    Maybe the "Why did ...?" can come across as confrontational. -- If something's good, you're less likely to ask "why do that?". "What Nix Flakes Solve" or "Benefits of Nix Flakes" would avoid that. But, I didn't read the title as provocative.
anotherhue 3y ago
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 package ecosystem (ten years old now), but it needs to spread its wings.
- Arnavion 3y ago
  >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.
  - anotherhue 3y ago
    Yes the OpenSSL one https://lists.debian.org/debian-security-announce/2008/msg00152.html 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 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.
  - pxc 3y ago
    > 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.
lima 3y ago
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!
- t0astbread 3y ago
  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`.
  - Filligree 3y ago
    Yes, but channels are updated less often and it's very unusual to put an application git repository into one. You might have two dozen flakes in your system. You'll typically only have a single channel, if you use them.
- pushtheenvelope 3y ago
  ah, yeah, we have a cheeky workaround for this in Devbox ;-) https://github.com/jetpack-io/devbox/blob/main/internal/impl/generate.go#L167 https://github.com/jetpack-io/devbox/blob/main/internal/impl...
- rnhmjoj 3y ago
  It's a known issue but fortunately is being worked on: https://github.com/NixOS/nix/pull/6530 https://github.com/NixOS/nix/pull/6530
  - tangjurine 3y ago
    Doesn't this still copy the repo, but just doesn't unzip it?
    - hamandcheese 3y ago
      I think it only lazily copies files that are referenced by your nix expression. I tested this branch, and a flake-based shell launched in 3 seconds inside a large monorepo (vs 30 seconds before). I don't think it is possible to copy this repo in 3 seconds.
Reventlov 3y ago
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.
- civilitty 3y ago
  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
  - lillecarl 3y ago
    It's a political thing, flakes are not going away or changing radically. Though the CLI commands aren't "stable" (guaranteed not to change wise). I read somewhere that someone of importance believes and thinks flakes will be enabled by default in 23.11 already.
- lucilleh 3y ago
  So...devbox adopted flakes before Nix did? lol.
  - lillecarl 3y ago
    Does anyone already rely on LLMs way too much? Yes, but nix is a lot more predictable than LLMs are. 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.
- takeda 3y ago
  The thing with nix is that features are experimental for a very long time, even though they are quite solid. It seems like it is mostly used so they can still make changes, like the CLI options or the names of attributes in the flake. The effort to use it is just adding extra line to the config.
- SkyMarshal 3y ago
soupbowl 3y ago
I find the default way to work with nixos to be a lot easier to use compared to flakes. I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. I don't think that is a positive.
- VTimofeenko 3y ago
  It is possible to use flakes on systems otherwise managed with channels. Just enable the "nix-command flakes" experimental features[1] and stuff like "nix run" will work. [1]: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes section "Enable Flakes".
- rgoulter 3y ago
  > I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. AFAIR, the only irreversible impact is switching from `nix-env --install` to `nix profile install`. With repositories, you can add a flake.nix, and still use nix-build or nix-shell however you did before. e.g. You can have the flake.nix import the default.nix or shell.nix code.
- Cloudef 3y ago
  Pretty much, still not sold on flakes. My nixpkgs is also git repo not channel
commandersaki 3y ago
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.
- aliasxneo 3y ago
  Depends on the person. I work in a company that uses Nix for everything one could possibly imagine, and I've found there are a few types of people: 1. The purist: Is on an actual crusade to promote Nix and stomp out any competition, because, "reproducible." 2. The enthusiast: Likes using Nix to speed up development but recognizes it has a ton of shortcomings, among others being not friendly to beginners, and tends to avoid using it in production critical stuff. 3. The ex-Nix: matches the enthusiasm of the purist in stomping out Nix wherever possible and actively promoting its demise. I'm personally in the second category. I use Nixos for my main development machine and really like devshells. Beyond that, I try to avoid it as much as possible for production.
  - hellcow 3y ago
    We use it for devshells, and it’s awesome. New devs install nix and direnv and they instantly have all the right versions of all of our tooling. A first day setup process is now done in minutes instead of a day. Flakes made it possible for us to package up internal and external tools and ensure consistency across a team. I have no experience running it in production, but I imagine if you don’t want to use containers it’d be a pretty good option.
    - ghuntley 3y ago
      for devshells use https://devenv.sh https://devenv.sh
  - ParetoOptimal 3y ago
    I'm kinda 1 & 2, sometimes one much more than the other.
  - Sirenos 3y ago
0x69420 3y ago
the article does a good job of explaining why something like the flake system was necessary, but man oh man does the particular thing we wound up with have issues. you can smell from a mile away that they were engineered to solve widely-experienced problems... as experienced by a single company, with an existing, idiosyncratic set of methodologies. and they just happened to get the blessing because eelco was at that company. unlike nix proper, however, where eelco had the entire internet for feedback, the core design of flakes ossified before the world at large had reason to care about them. it doesn't help that nix's command-line ux is currently super splintered as a result, and while that will be ironed out in the long run, the thing in the name of which those tools got splintered is rather insulting. i love nix but god damn this is the stage at which i'd take someone to couples counseling
heleninboodler 3y ago
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.
- dvdkon 3y ago
  "--" 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.
  - heleninboodler 3y ago
    It was the "#". I didn't realize that about the behavior in the middle of a token, and apparently the syntax colorizer doesn't either.
  - Izkata 3y ago
    > one that customarily means "pass the rest of arguments on to a subprocess". It's convenient for passing options and args to a subprocess, but it customarily means "don't interpret anything following this as a short or long option, just as a positional argument". For example: touch -f # error touch -- -f # creates a file named "-f" rm * # oh crap we just passed "rm -f" a bunch of files rm -- * # don't treat that "-f" as an option, just delete the file named "-f"
- femiagbabiaka 3y ago
  https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.
- pushtheenvelope 3y ago
  yikes! thanks for pointing that out. The blog's renderer is confused too and renders the `#cowsay -- flakes are neat` as a comment. To explain what's happening: - The example above is running `nix run <flake output attribute> -- <arguments to pass to the flake output's binary>`. - The `<flake output attribute>` here is `.#cowsay`, which is to be read as: `<flake reference>#<attribute path>`. The # is a separator here. - The `<flake reference>` being `.` implies its a local flake at the current directory. The `<attribute path>` in this case is the output from the flake i.e. the `cowsay` program. further fun to be found at: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix.html#flake-output-attribute https://nixos.org/manual/nix/stable/command-ref/new-cli/nix.... As a meta-comment, yeah, this is kinda non-trivial for most of us. This is why we build devbox which provides a more familiar UX like `devbox add cowsay && devbox run -- cowsay "flakes are neat"`
jonhohle 3y ago
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 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.
- georgyo 3y ago
  I don't fully understand what you are saying, and I don't know what systems you're including in "all". 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.
  - jonhohle 3y ago
    RPM rspecs, port Makefiles, Maven, etc. do not just define package dependencies (build, runtime, etc.) and artifacts, they also have to intimately understand how to patch, build, and package the artifacts. Making the build and package system separate from the dependency management separates concerns and allows the ability for a completely declarative “dumb” dependency graph that can be reasoned about without dealing with build logic that must be executed. This also allows build processes to evolve without affecting the public dependency graph. This makes it easier to show dependencies are modeled and exposed correctly and makes build logic private to consumers.
    - pxc 3y ago
predictabl3 3y ago
Flakes rule, impure eval drools. 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.
rgoulter 3y ago
I think the second point (nix flakes avoid 'stateful' channels) is the more compelling one. I don't recall an easy way for ensuring channels on different systems pointed to the same value; and flakes basically do what Niv did. And, it's much nicer to just install a flake, rather than having to add channels. I'm glad to see the first point (flake.nix provides a consistent interface) mentioned. The consistent interface allows for the cli to be much nicer; `nix flake show` can list the outputs.
toastal 3y ago
I prefer Flakes non-Flakes, but it’s disappointing that you can’t specify mirrors unlike the fetch* commands. Things go down on the internet & mirrors are a way to cover that sitution. There’s nothing like a failing CI because the one of the origin’s servers are down.
- tracnar 3y ago
  I thought that this option solved this problem? https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-hashed-mirrors https://nixos.org/manual/nix/stable/command-ref/conf-file.ht... But with the myriad of fetch* functions maybe it only applies to some.

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

pushtheenvelope 3y ago
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!
- seabass-labrax 3y ago
  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?
  - pushtheenvelope 3y ago
    s/adopt/introduce done :)
    - seabass-labrax 3y ago
      Thank you; that was quick! :) I apologise if my original comment came across as rather harsh!
      - pushtheenvelope 3y ago
        idk, someone (moderator?) changed it back ...
toolz 3y ago
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.
- rgoulter 3y ago
  Maybe the "Why did ...?" can come across as confrontational. -- If something's good, you're less likely to ask "why do that?". "What Nix Flakes Solve" or "Benefits of Nix Flakes" would avoid that. But, I didn't read the title as provocative.

anotherhue 3y ago

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 package ecosystem (ten years old now), but it needs to spread its wings.

Arnavion 3y ago
>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.
- anotherhue 3y ago
  Yes the OpenSSL one https://lists.debian.org/debian-security-announce/2008/msg00152.html 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 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.
- pxc 3y ago
  > 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.

lima 3y ago

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!

t0astbread 3y ago
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`.
- Filligree 3y ago
  Yes, but channels are updated less often and it's very unusual to put an application git repository into one. You might have two dozen flakes in your system. You'll typically only have a single channel, if you use them.
pushtheenvelope 3y ago
ah, yeah, we have a cheeky workaround for this in Devbox ;-) https://github.com/jetpack-io/devbox/blob/main/internal/impl/generate.go#L167 https://github.com/jetpack-io/devbox/blob/main/internal/impl...
rnhmjoj 3y ago
It's a known issue but fortunately is being worked on: https://github.com/NixOS/nix/pull/6530 https://github.com/NixOS/nix/pull/6530
- tangjurine 3y ago
  Doesn't this still copy the repo, but just doesn't unzip it?
  - hamandcheese 3y ago
    I think it only lazily copies files that are referenced by your nix expression. I tested this branch, and a flake-based shell launched in 3 seconds inside a large monorepo (vs 30 seconds before). I don't think it is possible to copy this repo in 3 seconds.

Reventlov 3y ago

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.

civilitty 3y ago
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
- lillecarl 3y ago
  It's a political thing, flakes are not going away or changing radically. Though the CLI commands aren't "stable" (guaranteed not to change wise). I read somewhere that someone of importance believes and thinks flakes will be enabled by default in 23.11 already.
lucilleh 3y ago
So...devbox adopted flakes before Nix did? lol.
- lillecarl 3y ago
  Does anyone already rely on LLMs way too much? Yes, but nix is a lot more predictable than LLMs are. 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.
takeda 3y ago
The thing with nix is that features are experimental for a very long time, even though they are quite solid. It seems like it is mostly used so they can still make changes, like the CLI options or the names of attributes in the flake. The effort to use it is just adding extra line to the config.
SkyMarshal 3y ago

soupbowl 3y ago

I find the default way to work with nixos to be a lot easier to use compared to flakes. I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. I don't think that is a positive.

VTimofeenko 3y ago
It is possible to use flakes on systems otherwise managed with channels. Just enable the "nix-command flakes" experimental features[1] and stuff like "nix run" will work. [1]: https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes section "Enable Flakes".
rgoulter 3y ago
> I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. AFAIR, the only irreversible impact is switching from `nix-env --install` to `nix profile install`. With repositories, you can add a flake.nix, and still use nix-build or nix-shell however you did before. e.g. You can have the flake.nix import the default.nix or shell.nix code.
Cloudef 3y ago
Pretty much, still not sold on flakes. My nixpkgs is also git repo not channel

commandersaki 3y ago

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.

aliasxneo 3y ago
Depends on the person. I work in a company that uses Nix for everything one could possibly imagine, and I've found there are a few types of people: 1. The purist: Is on an actual crusade to promote Nix and stomp out any competition, because, "reproducible." 2. The enthusiast: Likes using Nix to speed up development but recognizes it has a ton of shortcomings, among others being not friendly to beginners, and tends to avoid using it in production critical stuff. 3. The ex-Nix: matches the enthusiasm of the purist in stomping out Nix wherever possible and actively promoting its demise. I'm personally in the second category. I use Nixos for my main development machine and really like devshells. Beyond that, I try to avoid it as much as possible for production.
- hellcow 3y ago
  We use it for devshells, and it’s awesome. New devs install nix and direnv and they instantly have all the right versions of all of our tooling. A first day setup process is now done in minutes instead of a day. Flakes made it possible for us to package up internal and external tools and ensure consistency across a team. I have no experience running it in production, but I imagine if you don’t want to use containers it’d be a pretty good option.
  - ghuntley 3y ago
    for devshells use https://devenv.sh https://devenv.sh
- ParetoOptimal 3y ago
  I'm kinda 1 & 2, sometimes one much more than the other.
- Sirenos 3y ago

0x69420 3y ago

the article does a good job of explaining why something like the flake system was necessary, but man oh man does the particular thing we wound up with have issues. you can smell from a mile away that they were engineered to solve widely-experienced problems... as experienced by a single company, with an existing, idiosyncratic set of methodologies. and they just happened to get the blessing because eelco was at that company. unlike nix proper, however, where eelco had the entire internet for feedback, the core design of flakes ossified before the world at large had reason to care about them. it doesn't help that nix's command-line ux is currently super splintered as a result, and while that will be ironed out in the long run, the thing in the name of which those tools got splintered is rather insulting. i love nix but god damn this is the stage at which i'd take someone to couples counseling

heleninboodler 3y ago

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.

dvdkon 3y ago
"--" 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.
- heleninboodler 3y ago
  It was the "#". I didn't realize that about the behavior in the middle of a token, and apparently the syntax colorizer doesn't either.
- Izkata 3y ago
  > one that customarily means "pass the rest of arguments on to a subprocess". It's convenient for passing options and args to a subprocess, but it customarily means "don't interpret anything following this as a short or long option, just as a positional argument". For example: touch -f # error touch -- -f # creates a file named "-f" rm * # oh crap we just passed "rm -f" a bunch of files rm -- * # don't treat that "-f" as an option, just delete the file named "-f"
femiagbabiaka 3y ago
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1... The first -- argument that is not an option-argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character.
pushtheenvelope 3y ago
yikes! thanks for pointing that out. The blog's renderer is confused too and renders the `#cowsay -- flakes are neat` as a comment. To explain what's happening: - The example above is running `nix run <flake output attribute> -- <arguments to pass to the flake output's binary>`. - The `<flake output attribute>` here is `.#cowsay`, which is to be read as: `<flake reference>#<attribute path>`. The # is a separator here. - The `<flake reference>` being `.` implies its a local flake at the current directory. The `<attribute path>` in this case is the output from the flake i.e. the `cowsay` program. further fun to be found at: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix.html#flake-output-attribute https://nixos.org/manual/nix/stable/command-ref/new-cli/nix.... As a meta-comment, yeah, this is kinda non-trivial for most of us. This is why we build devbox which provides a more familiar UX like `devbox add cowsay && devbox run -- cowsay "flakes are neat"`

jonhohle 3y ago

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

georgyo 3y ago
I don't fully understand what you are saying, and I don't know what systems you're including in "all". 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.
- jonhohle 3y ago
  RPM rspecs, port Makefiles, Maven, etc. do not just define package dependencies (build, runtime, etc.) and artifacts, they also have to intimately understand how to patch, build, and package the artifacts. Making the build and package system separate from the dependency management separates concerns and allows the ability for a completely declarative “dumb” dependency graph that can be reasoned about without dealing with build logic that must be executed. This also allows build processes to evolve without affecting the public dependency graph. This makes it easier to show dependencies are modeled and exposed correctly and makes build logic private to consumers.
  - pxc 3y ago

predictabl3 3y ago

Flakes rule, impure eval drools. 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.

rgoulter 3y ago

I think the second point (nix flakes avoid 'stateful' channels) is the more compelling one. I don't recall an easy way for ensuring channels on different systems pointed to the same value; and flakes basically do what Niv did. And, it's much nicer to just install a flake, rather than having to add channels. I'm glad to see the first point (flake.nix provides a consistent interface) mentioned. The consistent interface allows for the cli to be much nicer; `nix flake show` can list the outputs.

toastal 3y ago

I prefer Flakes non-Flakes, but it’s disappointing that you can’t specify mirrors unlike the fetch* commands. Things go down on the internet & mirrors are a way to cover that sitution. There’s nothing like a failing CI because the one of the origin’s servers are down.

tracnar 3y ago
I thought that this option solved this problem? https://nixos.org/manual/nix/stable/command-ref/conf-file.html#conf-hashed-mirrors https://nixos.org/manual/nix/stable/command-ref/conf-file.ht... But with the myriad of fetch* functions maybe it only applies to some.