[HN Gopher] Why did Nix adopt Flakes?
___________________________________________________________________
Why did Nix adopt Flakes?
Author : pushtheenvelope
Score : 65 points
Date : 2023-06-16 19:12 UTC (3 hours ago)
(HTM) web link (www.jetpack.io)
(TXT) w3m dump (www.jetpack.io)
| heleninboodler wrote:
| 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.
| pushtheenvelope wrote:
| 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 reference> --
| <arguments to pass to the flake output's binary>`.
|
| - The `<flake reference>` here is `.#cowsay`, which is to be
| read as: `<flake type>#<output from flake>`. The # is a
| separator here.
|
| - The `<flake type>` being `.` implies its a local flake at the
| current directory. The `<output from flake` in this case is the
| `cowsay` program.
|
| further fun to be found at:
| https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...
|
| 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"`
| dvdkon wrote:
| "--" 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 wrote:
| 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.
| femiagbabiaka wrote:
| 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.
| anotherhue wrote:
| 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.
| pushtheenvelope wrote:
| I love the analogy!
|
| 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.
| Arnavion wrote:
| >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 wrote:
| > 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._
| anotherhue wrote:
| 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.
| soupbowl wrote:
| 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 wrote:
| 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 section "Enable Flakes".
| lima wrote:
| 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!
| pushtheenvelope wrote:
| ah, yeah, we have a cheeky workaround for this in Devbox ;-)
|
| https://github.com/jetpack-io/devbox/blob/main/internal/impl...
| madjam002 wrote:
| Yeah this is annoying purely from a disk space perspective too
| as I easily go through 200GB of disk space in a day if I'm
| actively working and iterating on some Nix code
| yakshaving_jgt wrote:
| Is this still an issue when using gitignoreSrc?
|
| https://github.com/hercules-ci/gitignore.nix
| hamandcheese wrote:
| For me, yes. Even with a completely clean checkout, the repo
| is a few hundred megs.
| rnhmjoj wrote:
| It's a known issue but fortunately is being worked on:
| https://github.com/NixOS/nix/pull/6530
| tangjurine wrote:
| Doesn't this still copy the repo, but just doesn't unzip it?
| hamandcheese wrote:
| 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.
| takeda wrote:
| I hope that helps with nixpkgs repo as this takes a lot
| of time whenever it is updated.
| t0astbread wrote:
| 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`.
| seabass-labrax wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| s/adopt/introduce
|
| done :)
| seabass-labrax wrote:
| Thank you; that was quick! :) I apologise if my original
| comment came across as rather harsh!
| pushtheenvelope wrote:
| idk, someone (moderator?) changed it back ...
| toolz wrote:
| 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.
| Reventlov wrote:
| 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.
| SkyMarshal wrote:
| Even after it passes the experimental stage, I doubt they'll
| drop support for the default install/config method using
| configuration.nix. Flakes will just another option but not
| required.
| lucilleh wrote:
| So...devbox adopted flakes before Nix did? lol.
| civilitty wrote:
| 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
| takeda wrote:
| 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.
| 0x69420 wrote:
| 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
| commandersaki wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| for devshells use https://devenv.sh
| xaduha wrote:
| I'd start by using Home Manager which is a way to use nix
| packages in a sensible manner on any distro.
|
| https://nix-community.github.io/home-manager/index.html
| jljljl wrote:
| If you like the properties of Nix, but find it confusing, you
| should check out Devbox! It simplifies the process of creating
| Nix-powered dev environments:
|
| https://github.com/jetpack-io/devbox
___________________________________________________________________
(page generated 2023-06-16 23:00 UTC)