12 ms·

NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

242 points by seabass-labrax 3y ago

whateveracct 3y ago
Sweet! That'll give people some clarity. Flakes have been great.
setheron 3y ago
I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability. I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)
- jchw 3y ago
  The thing I actually love about Flakes is the fact that my immutable system configuration now also contains the versions of dependencies, instead of them being in some out-of-band special area. This is super nice for rollbacks and just general visibility. It's even more of a plus that it is aware of Git and makes rather surprisingly intelligent decisions when automatically upgrading the system on a schedule (as one example, it seems to be able to deal with when the Git repository has staged or unstaged changes just fine, producing commits with just the lockfile changes.)
- whateveracct 3y ago
  Luckily, you can still use niv! I still am for certain projects. It works so well for what it does. Flakes give a little more ofc.
- biggestlou 3y ago
  Niv is fine and good but there's a lot that it will never provide, like the ability to `nix run` packages or `nix flake show` what your project provides with only a URL in hand.
  - setheron 3y ago
    You can still `nix run` packages using niv -- no clue what you talking about. You can also just look at the niv sources.json file pretty easily if you knew the URL. Rather trivial command to run. I don't find the above compelling (or correct?)
    - biggestlou 3y ago
      nix run github:DeterminateSystems/flake-checker What's the Niv equivalent of this?
      - setheron 3y ago
        # non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix # flake $ nix run github:fzakaria/mvn2nix#mvn2nix
        biggestlou 3y ago
        mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?
        setheron 3y ago
        I actually support both by having default.nix At this point I recommend we take this through another medium like email or feel free to open up a discourse to help fill in the knowledge gap. Feel free to tag me on it.
        pxc 3y ago
        The -f is for 'file', and when you point it at a directory or repo/archive path, it resolves to a default.nix file rather than a flake.nix file.
- solomonb 3y ago
  You absolutely do not need flake-parts.
  - mongol 3y ago
    What is it even? I see it referenced now and then and don't understand in what situations it would be useful.
    - solomonb 3y ago
      It adds a module system to nix flakes. I've been using nix every day for 4 years and make heavy use of flakes but TBH i'm not really sure the benefit flake-parts. It looks like a ton of new boilerplate.
- RaitoBezarius 3y ago
  I moved to npins which has slightly more features that niv. But niv has been great, I wish we can have patching natively so all my tons of patches can be bolted on faster.
- predictabl3 3y ago
  Except that niv doesn't ensure pure evaluation, and thus a number of non-flakes, niv-friendly projects are unusable with flakes, and are often difficult to work with otherwise due to their impurities. It also can't do transient overrides which is quite literally the essential reason that Flakes is killer to me. For example, I can cross-compile to riscv64-linux, including a bunch of 3rd party flakes repos *specifically* because I refer to them and then override their nixpkgs to point to my nixpkgs with various cross-compilation fixes. Definitely not possible to do this with niv. It also does nothing to solve the countless issues with channels that I've watched afflict countless new Nix users, every week, for 3+ years. [insert the usual 8-stop troubleshoot list when a user has any issue possibly related to channels]
  - setheron 3y ago
    I tend to just override nixpkgs downstream. I think the situation you are describing is more power-user. Flakes to me introduced a lot of overhead beyond what niv can provide. I get 99% value just pinning my top level dependencies since most of the time I'm referring nixpkgs + 1-2 other packages.
m1keil 3y ago
> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?
- nextos 3y ago
  Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels.
  - PuercoPop 3y ago
    I use nix with flakes, have written a couple of flakes day to day use. I am not a nix power user. But based on my current understanding this statement seems incorrect > Flakes are tightly coupled to Git. How is it tightly coupled to Git if it supports Mercurial out of the box? Other than using version control to determine what are the sources of the derivation, what does flakes lean on version control?
    - nextos 3y ago
      I meant this kind of issue: https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-repo-without-committing-flake-nix/18196 https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-...
      - PuercoPop 3y ago
        That is what I was trying to say by > Other than using version control to determine what are the sources of the derivation I don't think that defaulting to using git to list the sources when inside a git repo means that it is tightly coupled to git. If one doesn't want to commit/stage the flake files in the repo one can do `nix develop .` and it works . It will take a little longer because it will copy the entire directory to the store iiuc.
jsomedon 3y ago
I wanted to switch to nixos but current segregation between flakes and (traditional) nix features was a huge stop sign for me. Seems like this move is a good sign resolving this issue. Hope they bring things nice together -- features, doc, the community etc.
- whateveracct 3y ago
  I just started using flakes like a year and a half ago for my configs (easy nixpkgs pinning in git was worth it). No issues so far - take the plunge!
- sullyj3 3y ago
  I empathise with this uncertainty. As I understand it, flakes aren't incompatible with the previous way of doing things. Rather they represent an additional feature which can be used on top of them. For example if you have a shell.nix that you were running with `nix-shell` which defaults to using channels to obtain nixpkgs { pkgs ? import <nixpkgs> {} }: pkgs.mkShell { # ... You can reuse it in your flake.nix devShells.${system}.default = import ./shell.nix { inherit pkgs; }; And it will use the locked nixpkgs input defined in your flake. You can run it with the new `nix develop` command, but `nix-shell` will continue to work, giving you the previous behaviour.
bongobingo1 3y ago
Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux system? I dont really want to dump a working system and duel booting always has whatever you need on the other system. Do you get anything when not using NixOS to manage everything? What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix? Has anyone gone down this route? What is the actual lived experience of half-assing it?
- clhodapp 3y ago
  I use home-manager on Ubuntu on my work machine. You have to pay the full learning curve of Nix. Once you do, it works just fine. I think there comes a natural pressure to use Nix for as much as possible and slowly cut down one's dependency on the "base" system when you go this route. Maybe that's just because I want to see my investment in Nix pay off. I would say that the biggest benefit you get is the hugeness and currentness of nixpkgs and the fact that it becomes a lot less important what software you have "installed".
- pkulak 3y ago
  I don’t know the value of half-assing it, but committing your full ass is amazing. Don’t abandon a working system, but the next time you wait a whole three weeks to pacman -syu and your GPG keys are out of date and everything goes to hell… give it a shot. Honestly, it’s Home Manager that really adds the maximum value, and getting all the way there takes a full weekend, but what were you gonna do anyway?
  - tiffanyg 3y ago
    I don’t know the value of half-assing it, but committing your full ass is amazing. Indeed. As no less than Ron Swanson rendered unto us - an exemplar in classic American yarn form: https://youtu.be/k6hZ9KdG1QU https://youtu.be/k6hZ9KdG1QU ... wise words.
mikepurvis 3y ago
Fantastic! Happy flake user here who will be pleased to have the documentation updated and referring to the workflows we use.
bergkvist 3y ago
The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time than I'd like to admit wondering why what I'm building doesn't include my latest change. Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. This kind of copying would likely be a lot more acceptable if it was specified explicitly in flake.nix, rather than implicitly. Then you could also use your own filters for ignoring files, rather than relying on the coupling to git and its staging area.
- CuriousCosmic 3y ago
  > Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. Could you not just do a sparse checkout for monorepos? https://github.com/NixOS/nixpkgs/pull/135881 https://github.com/NixOS/nixpkgs/pull/135881
  - bergkvist 3y ago
    My use case here is not using pkgs.fetchgit etc - but rather when developing a package locally and rebuilding it. Let's say I'm working on a huge monorepo locally, with GBs of code and data in it, most of which I want to ignore in my nix build. Let's say the files I actually care about are also not in a single subfolder. Then I can't just move the flake.nix to that subfolder either.
    - CuriousCosmic 3y ago
      Oh yeah in that case it'd be a problem. There might be a way around that but that case definitely isn't ideal. albeit you could probably sparse-checkout your repo to avoid that if you don't need all of it. definitely not ideal and I agree that until lazy file mapping, content addressed derivations, and file deduplication get implemented that the UX will be rough in some cases.
1attice 3y ago
NixOS is honestly so beautiful and rare. I'm delighted that the project is moving forward in this way. A friend of mine called it a "rabbit hole" but TBH it's words of power -- I can speak new instances of my environment into existence, not only on newly-acquired compute devices, but on other OSes as well (I put some effort into segmenting the user environment and system config between home-manager and standard /etc/nixos/*) Nix flakes will only make me more powerful
- fortunateregard 3y ago
  > I can speak new instances of my environment into existence You're not kidding. I used nixos-anywhere [1] for the first time the other day. You can point it to any linux host and it will partition, format, and supplant the target's existing OS with your nixOS config, all with a single command. Incredible. [1] https://github.com/numtide/nixos-anywhere https://github.com/numtide/nixos-anywhere
EE84M3i 3y ago
Can someone that understands this "limbo" and "long standing tensions" give a TL;DR for someone that knows what flakes and the new cli are but hasn't been following the community discussions around it?
- yjftsjthsd-h 3y ago
  Flakes are amazing but have been designated as an unstable or beta feature for I think literally years now, which creates tension between the desire to get them polished and perfect and the desire to have them be the one true official way to do things already.
  - Macha 3y ago
    The prior system was also totally unopinionated, while Flakes prescribe a default path and some people are upset by this, too
pxc 3y ago
It feels really good to see this RFC cross the finish line into a finalized plan. The plan itself seems very well thought out. I had a vague desire for an incremental stabilization of flakes some time ago, but this is so much better. The flakes divide is one of the biggest remaining problemd facing the community, now that the issues with the release cycle have improved so much and continue to improve. Each step taken in executing this plan will be a real boon for the Nix community. Onward!
sourcegrift 3y ago
My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some reason I couldn't bring myself to learn flakes ... Although that could have been because they were in limbo. I have to say though, nix is increasingly becoming a nerd thing philosophizing over minute issues rather than "getting shit done" to benefit the maximum number of users ... :-(
- pkulak 3y ago
  I think we all have our own aha moments with things like this. I thought like you until I really dug in and set up Home Manager as well. My moment, and maybe this means nothing to you, was when I realized I could reference any package in a config file without even “installing” it. So it’s no longer that I have config files in Git somewhere, and then also a list of all the packages I need to install somewhere else; the config files themselves pull in the packages they need by virtue of referencing them. There are a million other things, but that’s when I was like, “Okay, I’m actually gonna do this.”
  - ibizaman 3y ago
    I’m maybe missing something but non-flake nix also pull packages by just referencing them. Right?
    - rgoulter 3y ago
      Yes, in Nix code it is possible to refer to arbitrary Nix codebases from Nix code. I'd point to the home-manager installation instructions for an example of Nix flakes having a nicer UX. Running flake-enabled codebases is just much nicer than non-flake codebases. https://nix-community.github.io/home-manager/index.html#sec-install-standalone https://nix-community.github.io/home-manager/index.html#sec-... https://nix-community.github.io/home-manager/index.html#sec-flakes-standalone https://nix-community.github.io/home-manager/index.html#sec-... The former involves running `nix-channel --add <...> home-manager && nix-channel --update` in order for `<home-manager>` to mean anything. With the latter, it's simply `nix run home-manager/release-23.05 -- init --switch`. (Albeit, `home-manager` is already registered as an alias for `github:nix-community/home-manager`). One key detail is that `nix-channel --add` modifies the 'system state', whereas running flakes essentially does not. -- Regarding "you can pull in arbitrary Nix code by reference". With flakes, you have a standard entry point where you know the interface it has. Whereas, having a 'default.nix' is a convention, and there's no way to know how a `default.nix` is to be used without reading its source.
toastal 3y ago
I hope the standardize on aliasing -ise and -ize endings in the CLI instead of throwing errors to folks just wanting to optmise or optimize because it shouldn’t matter.
duped 3y ago
I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.
- lloeki 3y ago
  > without double checking It's fine, Nix things are conceptually different from anything before. You could say flakes are like Rakefile, but that would be a lie. You could say they're like Gemfile and Gemfile.lock, but that would be a lie too. You could say that derivations are like packages, but that would be a lie, you could say they're like container images but that would be a lie too. Now, you can try to understand what these concepts are by mapping to known knowledge of other things in terms of use cases they solve, that's fine, but at their core these concepts are different and quite unique, so it only makes sense for them to have different names. Naming is hard, Nix folks had to pick one for each concept, and they chose not to lie by picking existing names that would not map and create bias in the understanding and expectations. It makes for a steeper learning curve, but I'd argue long term in the learning process it's the right move. Let me try to give some synthesised definitions (which may be incomplete and lies in the Feynman sense): - a derivation is the reification (or realisation, as in, "make it real") of a function call on the filesystem. IOW the concrete result is derived from the function call, memoized using content addressing. - a flake is a central definition of a number of target derivations in the context of a specific source state of dependencies. If you look at an actual (snow)flake there's this recursive/fractal design coming from a central point, which kind of visually represent the conceptual structure underpinning a nix flake. So for me the names totally make sense! But I can understand that they don't out of the blue (and they did not for me at first!) It turns out (not really by accident) that these cover use cases that were implemented by this or that tool, and instinctively through a partial understanding of the nix concepts we're in conflict: the other tools give us a (biased) understanding which both increases and is in conflict with our understanding of nix concepts. This is a normal process, but at some point by letting go of what we previously know and trying to understand new things for what they are and not what we project onto them, we open ourselves to fully grok, and both fully leverage the new concepts and realise their limitations.
aktuel 3y ago
One smaller UI improvement I would like to see is being able to retrieve the exact git commit of an installed flake. This seems not to be possible atm. Main argument for not having this is putting a reference to the git commit into the nix store folder would break hermetic evaluation. (You can habe multiple commits resulting in the same code.) It should however not be too hard to log that information separately somewhere else. It is somewhat disapointing for this link to be missing when flakes are already tied to git as they are. The log entries could also include a flag if the flake was installed "dirty" (having uncomitted changes at the time).
gallexme 3y ago
Love nix and flakes, can easily describe my whole infrastructure in nix(even generating terraform files from it, manage secrets(agenix,agenix-rekey), and dev tools required to work on parts of the infrastructure(LSP's, deploy-rs, secrets decrypting using ssh key,rekeying secrets to public keys of machines), all in one flake, one monorepo (virtually split up with the josh project into multiple repos with shared history,works really well) I love it, only thing I would love if there was a proper way for passing arguments to flakes for build /dev/run only dependencies and other ways to specialize the scope of the user using the flake and infrastructure attached to it :)
nektro 3y ago
i love nixos but flakes are not it
hlandau 3y ago
To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake utility repository. Having to rely on an unendorsed third party just to write architecture-independent code isn't very appealing to me. This seems like a serious deficiency in the design of Flakes, though it would be tolerable at least if this functionality was at least in Nixpkgs.
- smoldesu 3y ago
  I haven't personally found this to be an issue. I usually define the arches I intend to hit at the beginning of the flake, then pass that list to pkgs so it can track down the independent dependencies: allSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ]; forAllSystems = f: nixpkgs.lib.genAttrs allSystems (system: f { pkgs = import nixpkgs { inherit system; }; }); See? Easy as getting a tooth pulled!
- pmarreck 3y ago
  > they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous Well, we're talking about evaluating a pure function (literally the entire philosophy of Nix is treating a build like a pure function). Those things are variable state as an input which affects the output, and therefore must be specified as inputs. I don't see the problem here (if you have already accepted that you want to treat builds as pure functions with total encapsulation of the state required to run them, and thus having deterministic outcomes).
  - seabass-labrax 3y ago
    It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be helpful for completely architecture-less packages (such as interpreted scripts).
resonious 3y ago
Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand? Could spend that same time setting up an Ubuntu by hand each time followed by git pull or scp to deploy. Ended up using Ansible in the end, as it really does let me just get a new VPS and deploy to it very fast when the time comes. I wonder why the big providers once supported NixOS and then decided to stop!
- suchar 3y ago
  For DigitalOcean (and several other providers) you can build your own image with provided configurations, e.g.: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/digital-ocean-image.nix https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/v... (see `virtualisation` folder for other providers) Then you can do something like: nix build .#nixosConfigurations.doImage.system.build.digitalOceanImage And in the `result` directory you will have droplet image which can be uploaded to digital ocean as droplet template. Its probably best to also create separate configuration only for the image. As a bonus, its already configured, so no need to run `nixos-rebuild switch` after droplet creation. Partitioning configuration is also handled by the builded, however, filesystem choice (and partitioning schema) is limited (I'm not saying that this is easier than out of the box support for NixOS: IMO if you are even aware how to create custom NixOS image then you are probably somewhat experienced NixOS user)
- rgoulter 3y ago
  Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images. Sibling comment mentions that nix has ways to build NixOS VM images (e.g. https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators has a generator specifically for Linode). Another option is to use nixos-infect, which will replace a Linux distribution with a NixOS distribution. https://github.com/elitak/nixos-infect https://github.com/elitak/nixos-infect -- e.g. this blogpost discusses using nixos-infect to deploy NixOS for a cloud provider which doesn't have an official NixOS image. https://xeiaso.net/blog/nix-flakes-terraform https://xeiaso.net/blog/nix-flakes-terraform > At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand? Just as with ansible, "git pull to deploy". You'd keep a copy of your NixOS configuration.nix somewhere else, and would be able to apply it later. > it really does let me just get a new VPS and deploy to it very fast Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with. I believe much of the use of NixOS is for hobby stuff, and for personal machines. (c.f. "In what environments do you use Nix", Development (1242) vs Home Server (845) vs Production (386) https://discourse.nixos.org/t/2022-nix-survey-results/18983 https://discourse.nixos.org/t/2022-nix-survey-results/18983).

Sweet! That'll give people some clarity. Flakes have been great.

I'm still in the 'meh' camp for flakes. I use niv and it gives me enough usability. I find the need to include additional libraries to make flakes usable for some reason a weird hurdle I don't personally enjoy (i.e. flake-parts or systems)

jchw 3y ago
The thing I actually love about Flakes is the fact that my immutable system configuration now also contains the versions of dependencies, instead of them being in some out-of-band special area. This is super nice for rollbacks and just general visibility. It's even more of a plus that it is aware of Git and makes rather surprisingly intelligent decisions when automatically upgrading the system on a schedule (as one example, it seems to be able to deal with when the Git repository has staged or unstaged changes just fine, producing commits with just the lockfile changes.)
whateveracct 3y ago
Luckily, you can still use niv! I still am for certain projects. It works so well for what it does. Flakes give a little more ofc.
biggestlou 3y ago
Niv is fine and good but there's a lot that it will never provide, like the ability to `nix run` packages or `nix flake show` what your project provides with only a URL in hand.
- setheron 3y ago
  You can still `nix run` packages using niv -- no clue what you talking about. You can also just look at the niv sources.json file pretty easily if you knew the URL. Rather trivial command to run. I don't find the above compelling (or correct?)
  - biggestlou 3y ago
    nix run github:DeterminateSystems/flake-checker What's the Niv equivalent of this?
    - setheron 3y ago
      # non-flake $ nix run -f https://github.com/fzakaria/mvn2nix/archive/master.tar.gz https://github.com/fzakaria/mvn2nix/archive/master.tar.gz --command mvn2nix # flake $ nix run github:fzakaria/mvn2nix#mvn2nix
      - biggestlou 3y ago
        mvn2nix is a flake, though. How would I run a project that uses Niv and isn't a flake?
        setheron 3y ago
        I actually support both by having default.nix At this point I recommend we take this through another medium like email or feel free to open up a discourse to help fill in the knowledge gap. Feel free to tag me on it.
        pxc 3y ago
        The -f is for 'file', and when you point it at a directory or repo/archive path, it resolves to a default.nix file rather than a flake.nix file.
solomonb 3y ago
You absolutely do not need flake-parts.
- mongol 3y ago
  What is it even? I see it referenced now and then and don't understand in what situations it would be useful.
  - solomonb 3y ago
    It adds a module system to nix flakes. I've been using nix every day for 4 years and make heavy use of flakes but TBH i'm not really sure the benefit flake-parts. It looks like a ton of new boilerplate.
RaitoBezarius 3y ago
I moved to npins which has slightly more features that niv. But niv has been great, I wish we can have patching natively so all my tons of patches can be bolted on faster.
predictabl3 3y ago
Except that niv doesn't ensure pure evaluation, and thus a number of non-flakes, niv-friendly projects are unusable with flakes, and are often difficult to work with otherwise due to their impurities. It also can't do transient overrides which is quite literally the essential reason that Flakes is killer to me. For example, I can cross-compile to riscv64-linux, including a bunch of 3rd party flakes repos *specifically* because I refer to them and then override their nixpkgs to point to my nixpkgs with various cross-compilation fixes. Definitely not possible to do this with niv. It also does nothing to solve the countless issues with channels that I've watched afflict countless new Nix users, every week, for 3+ years. [insert the usual 8-stop troubleshoot list when a user has any issue possibly related to channels]
- setheron 3y ago
  I tend to just override nixpkgs downstream. I think the situation you are describing is more power-user. Flakes to me introduced a lot of overhead beyond what niv can provide. I get 99% value just pinning my top level dependencies since most of the time I'm referring nixpkgs + 1-2 other packages.

m1keil 3y ago

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?

nextos 3y ago
Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when using channels.
- PuercoPop 3y ago
  I use nix with flakes, have written a couple of flakes day to day use. I am not a nix power user. But based on my current understanding this statement seems incorrect > Flakes are tightly coupled to Git. How is it tightly coupled to Git if it supports Mercurial out of the box? Other than using version control to determine what are the sources of the derivation, what does flakes lean on version control?
  - nextos 3y ago
    I meant this kind of issue: https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-repo-without-committing-flake-nix/18196 https://discourse.nixos.org/t/can-i-use-flakes-within-a-git-...
    - PuercoPop 3y ago
      That is what I was trying to say by > Other than using version control to determine what are the sources of the derivation I don't think that defaulting to using git to list the sources when inside a git repo means that it is tightly coupled to git. If one doesn't want to commit/stage the flake files in the repo one can do `nix develop .` and it works . It will take a little longer because it will copy the entire directory to the store iiuc.

jsomedon 3y ago

I wanted to switch to nixos but current segregation between flakes and (traditional) nix features was a huge stop sign for me. Seems like this move is a good sign resolving this issue. Hope they bring things nice together -- features, doc, the community etc.

whateveracct 3y ago
I just started using flakes like a year and a half ago for my configs (easy nixpkgs pinning in git was worth it). No issues so far - take the plunge!
sullyj3 3y ago
I empathise with this uncertainty. As I understand it, flakes aren't incompatible with the previous way of doing things. Rather they represent an additional feature which can be used on top of them. For example if you have a shell.nix that you were running with `nix-shell` which defaults to using channels to obtain nixpkgs { pkgs ? import <nixpkgs> {} }: pkgs.mkShell { # ... You can reuse it in your flake.nix devShells.${system}.default = import ./shell.nix { inherit pkgs; }; And it will use the locked nixpkgs input defined in your flake. You can run it with the new `nix develop` command, but `nix-shell` will continue to work, giving you the previous behaviour.

bongobingo1 3y ago

Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux system? I dont really want to dump a working system and duel booting always has whatever you need on the other system. Do you get anything when not using NixOS to manage everything? What good is it if half my system is installed by pacman, half by asdf-per-project and the rest by nix? Has anyone gone down this route? What is the actual lived experience of half-assing it?

clhodapp 3y ago
I use home-manager on Ubuntu on my work machine. You have to pay the full learning curve of Nix. Once you do, it works just fine. I think there comes a natural pressure to use Nix for as much as possible and slowly cut down one's dependency on the "base" system when you go this route. Maybe that's just because I want to see my investment in Nix pay off. I would say that the biggest benefit you get is the hugeness and currentness of nixpkgs and the fact that it becomes a lot less important what software you have "installed".
pkulak 3y ago
I don’t know the value of half-assing it, but committing your full ass is amazing. Don’t abandon a working system, but the next time you wait a whole three weeks to pacman -syu and your GPG keys are out of date and everything goes to hell… give it a shot. Honestly, it’s Home Manager that really adds the maximum value, and getting all the way there takes a full weekend, but what were you gonna do anyway?
- tiffanyg 3y ago
  I don’t know the value of half-assing it, but committing your full ass is amazing. Indeed. As no less than Ron Swanson rendered unto us - an exemplar in classic American yarn form: https://youtu.be/k6hZ9KdG1QU https://youtu.be/k6hZ9KdG1QU ... wise words.

mikepurvis 3y ago

Fantastic! Happy flake user here who will be pleased to have the documentation updated and referring to the workflows we use.

bergkvist 3y ago

The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time than I'd like to admit wondering why what I'm building doesn't include my latest change. Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. This kind of copying would likely be a lot more acceptable if it was specified explicitly in flake.nix, rather than implicitly. Then you could also use your own filters for ignoring files, rather than relying on the coupling to git and its staging area.

CuriousCosmic 3y ago
> Flakes copy the entire directory into the nix store. This is terrible for mono-repos - and especially if it contains any large files. There is an issue about making the copying of the entire directory into /nix/store lazy - though this doesn't really address the problem. It just treats some common symptoms. Could you not just do a sparse checkout for monorepos? https://github.com/NixOS/nixpkgs/pull/135881 https://github.com/NixOS/nixpkgs/pull/135881
- bergkvist 3y ago
  My use case here is not using pkgs.fetchgit etc - but rather when developing a package locally and rebuilding it. Let's say I'm working on a huge monorepo locally, with GBs of code and data in it, most of which I want to ignore in my nix build. Let's say the files I actually care about are also not in a single subfolder. Then I can't just move the flake.nix to that subfolder either.
  - CuriousCosmic 3y ago
    Oh yeah in that case it'd be a problem. There might be a way around that but that case definitely isn't ideal. albeit you could probably sparse-checkout your repo to avoid that if you don't need all of it. definitely not ideal and I agree that until lazy file mapping, content addressed derivations, and file deduplication get implemented that the UX will be rough in some cases.

1attice 3y ago

NixOS is honestly so beautiful and rare. I'm delighted that the project is moving forward in this way. A friend of mine called it a "rabbit hole" but TBH it's words of power -- I can speak new instances of my environment into existence, not only on newly-acquired compute devices, but on other OSes as well (I put some effort into segmenting the user environment and system config between home-manager and standard /etc/nixos/*) Nix flakes will only make me more powerful

fortunateregard 3y ago
> I can speak new instances of my environment into existence You're not kidding. I used nixos-anywhere [1] for the first time the other day. You can point it to any linux host and it will partition, format, and supplant the target's existing OS with your nixOS config, all with a single command. Incredible. [1] https://github.com/numtide/nixos-anywhere https://github.com/numtide/nixos-anywhere

EE84M3i 3y ago

Can someone that understands this "limbo" and "long standing tensions" give a TL;DR for someone that knows what flakes and the new cli are but hasn't been following the community discussions around it?

yjftsjthsd-h 3y ago
Flakes are amazing but have been designated as an unstable or beta feature for I think literally years now, which creates tension between the desire to get them polished and perfect and the desire to have them be the one true official way to do things already.
- Macha 3y ago
  The prior system was also totally unopinionated, while Flakes prescribe a default path and some people are upset by this, too

pxc 3y ago

It feels really good to see this RFC cross the finish line into a finalized plan. The plan itself seems very well thought out. I had a vague desire for an incremental stabilization of flakes some time ago, but this is so much better. The flakes divide is one of the biggest remaining problemd facing the community, now that the issues with the release cycle have improved so much and continue to improve. Each step taken in executing this plan will be a real boon for the Nix community. Onward!

sourcegrift 3y ago

My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some reason I couldn't bring myself to learn flakes ... Although that could have been because they were in limbo. I have to say though, nix is increasingly becoming a nerd thing philosophizing over minute issues rather than "getting shit done" to benefit the maximum number of users ... :-(

pkulak 3y ago
I think we all have our own aha moments with things like this. I thought like you until I really dug in and set up Home Manager as well. My moment, and maybe this means nothing to you, was when I realized I could reference any package in a config file without even “installing” it. So it’s no longer that I have config files in Git somewhere, and then also a list of all the packages I need to install somewhere else; the config files themselves pull in the packages they need by virtue of referencing them. There are a million other things, but that’s when I was like, “Okay, I’m actually gonna do this.”
- ibizaman 3y ago
  I’m maybe missing something but non-flake nix also pull packages by just referencing them. Right?
  - rgoulter 3y ago
    Yes, in Nix code it is possible to refer to arbitrary Nix codebases from Nix code. I'd point to the home-manager installation instructions for an example of Nix flakes having a nicer UX. Running flake-enabled codebases is just much nicer than non-flake codebases. https://nix-community.github.io/home-manager/index.html#sec-install-standalone https://nix-community.github.io/home-manager/index.html#sec-... https://nix-community.github.io/home-manager/index.html#sec-flakes-standalone https://nix-community.github.io/home-manager/index.html#sec-... The former involves running `nix-channel --add <...> home-manager && nix-channel --update` in order for `<home-manager>` to mean anything. With the latter, it's simply `nix run home-manager/release-23.05 -- init --switch`. (Albeit, `home-manager` is already registered as an alias for `github:nix-community/home-manager`). One key detail is that `nix-channel --add` modifies the 'system state', whereas running flakes essentially does not. -- Regarding "you can pull in arbitrary Nix code by reference". With flakes, you have a standard entry point where you know the interface it has. Whereas, having a 'default.nix' is a convention, and there's no way to know how a `default.nix` is to be used without reading its source.

toastal 3y ago

I hope the standardize on aliasing -ise and -ize endings in the CLI instead of throwing errors to folks just wanting to optmise or optimize because it shouldn’t matter.

duped 3y ago

I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.

lloeki 3y ago
> without double checking It's fine, Nix things are conceptually different from anything before. You could say flakes are like Rakefile, but that would be a lie. You could say they're like Gemfile and Gemfile.lock, but that would be a lie too. You could say that derivations are like packages, but that would be a lie, you could say they're like container images but that would be a lie too. Now, you can try to understand what these concepts are by mapping to known knowledge of other things in terms of use cases they solve, that's fine, but at their core these concepts are different and quite unique, so it only makes sense for them to have different names. Naming is hard, Nix folks had to pick one for each concept, and they chose not to lie by picking existing names that would not map and create bias in the understanding and expectations. It makes for a steeper learning curve, but I'd argue long term in the learning process it's the right move. Let me try to give some synthesised definitions (which may be incomplete and lies in the Feynman sense): - a derivation is the reification (or realisation, as in, "make it real") of a function call on the filesystem. IOW the concrete result is derived from the function call, memoized using content addressing. - a flake is a central definition of a number of target derivations in the context of a specific source state of dependencies. If you look at an actual (snow)flake there's this recursive/fractal design coming from a central point, which kind of visually represent the conceptual structure underpinning a nix flake. So for me the names totally make sense! But I can understand that they don't out of the blue (and they did not for me at first!) It turns out (not really by accident) that these cover use cases that were implemented by this or that tool, and instinctively through a partial understanding of the nix concepts we're in conflict: the other tools give us a (biased) understanding which both increases and is in conflict with our understanding of nix concepts. This is a normal process, but at some point by letting go of what we previously know and trying to understand new things for what they are and not what we project onto them, we open ourselves to fully grok, and both fully leverage the new concepts and realise their limitations.

aktuel 3y ago

One smaller UI improvement I would like to see is being able to retrieve the exact git commit of an installed flake. This seems not to be possible atm. Main argument for not having this is putting a reference to the git commit into the nix store folder would break hermetic evaluation. (You can habe multiple commits resulting in the same code.) It should however not be too hard to log that information separately somewhere else. It is somewhat disapointing for this link to be missing when flakes are already tied to git as they are. The log entries could also include a flag if the flake was installed "dirty" (having uncomitted changes at the time).

gallexme 3y ago

Love nix and flakes, can easily describe my whole infrastructure in nix(even generating terraform files from it, manage secrets(agenix,agenix-rekey), and dev tools required to work on parts of the infrastructure(LSP's, deploy-rs, secrets decrypting using ssh key,rekeying secrets to public keys of machines), all in one flake, one monorepo (virtually split up with the josh project into multiple repos with shared history,works really well) I love it, only thing I would love if there was a proper way for passing arguments to flakes for build /dev/run only dependencies and other ways to specialize the scope of the user using the flake and infrastructure attached to it :)

nektro 3y ago

i love nixos but flakes are not it

hlandau 3y ago

To date I've paid no attention to Flakes because whenever I look at them, they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous. I'm not going to make the code I publish needlessly dependent on specific architectures. This problem seems to be solved commonly in two ways: - People thoughtlessly and senselessly listing only x86; - People using the popular flake utility repository. Having to rely on an unendorsed third party just to write architecture-independent code isn't very appealing to me. This seems like a serious deficiency in the design of Flakes, though it would be tolerable at least if this functionality was at least in Nixpkgs.

smoldesu 3y ago
I haven't personally found this to be an issue. I usually define the arches I intend to hit at the beginning of the flake, then pass that list to pkgs so it can track down the independent dependencies: allSystems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ]; forAllSystems = f: nixpkgs.lib.genAttrs allSystems (system: f { pkgs = import nixpkgs { inherit system; }; }); See? Easy as getting a tooth pulled!
pmarreck 3y ago
> they appear to require me to manually list all target architectures in the Flakes file, which is ridiculous Well, we're talking about evaluating a pure function (literally the entire philosophy of Nix is treating a build like a pure function). Those things are variable state as an input which affects the output, and therefore must be specified as inputs. I don't see the problem here (if you have already accepted that you want to treat builds as pure functions with total encapsulation of the state required to run them, and thus having deterministic outcomes).
- seabass-labrax 3y ago
  It would be nice to have a shorthand value that means "evaluate this pure function exactly the same way regardless of the 'system' parameter", which would be helpful for completely architecture-less packages (such as interpreted scripts).

resonious 3y ago

Just today I was setting up a server for a side project and mulling over do I use ol' reliable Ubuntu+Ansible vs finally trying NixOS. I was very sad to see that all of the popular VPS services (Digital Ocean and the like) "no longer" officially support NixOS. Linode was nice enough to have an official "how to set up NixOS on Linode" guide, but it requires fiddling with partitions by hand. At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand? Could spend that same time setting up an Ubuntu by hand each time followed by git pull or scp to deploy. Ended up using Ansible in the end, as it really does let me just get a new VPS and deploy to it very fast when the time comes. I wonder why the big providers once supported NixOS and then decided to stop!

suchar 3y ago
For DigitalOcean (and several other providers) you can build your own image with provided configurations, e.g.: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/digital-ocean-image.nix https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/v... (see `virtualisation` folder for other providers) Then you can do something like: nix build .#nixosConfigurations.doImage.system.build.digitalOceanImage And in the `result` directory you will have droplet image which can be uploaded to digital ocean as droplet template. Its probably best to also create separate configuration only for the image. As a bonus, its already configured, so no need to run `nixos-rebuild switch` after droplet creation. Partitioning configuration is also handled by the builded, however, filesystem choice (and partitioning schema) is limited (I'm not saying that this is easier than out of the box support for NixOS: IMO if you are even aware how to create custom NixOS image then you are probably somewhat experienced NixOS user)
rgoulter 3y ago
Those Linode instructions are about installing an OS from an installation ISO from Linode's rescue mode. -- I'd consider that more a 'plus' to Linode that you get to be able to install whatever unsupported Linux on Linode's VMs. But, of course it's not as smooth as the officially supported images. Sibling comment mentions that nix has ways to build NixOS VM images (e.g. https://github.com/nix-community/nixos-generators https://github.com/nix-community/nixos-generators has a generator specifically for Linode). Another option is to use nixos-infect, which will replace a Linux distribution with a NixOS distribution. https://github.com/elitak/nixos-infect https://github.com/elitak/nixos-infect -- e.g. this blogpost discusses using nixos-infect to deploy NixOS for a cloud provider which doesn't have an official NixOS image. https://xeiaso.net/blog/nix-flakes-terraform https://xeiaso.net/blog/nix-flakes-terraform > At that point, I feel like all of the repeatability gains are gone. If I want to spin up a fresh server, I have to read a guide and set stuff up by hand? Just as with ansible, "git pull to deploy". You'd keep a copy of your NixOS configuration.nix somewhere else, and would be able to apply it later. > it really does let me just get a new VPS and deploy to it very fast Using a tool you're familiar with to get the job done is going to be faster than learning to use a tool you're unfamiliar with. I believe much of the use of NixOS is for hobby stuff, and for personal machines. (c.f. "In what environments do you use Nix", Development (1242) vs Home Server (845) vs Production (386) https://discourse.nixos.org/t/2022-nix-survey-results/18983 https://discourse.nixos.org/t/2022-nix-survey-results/18983).