Comment by lolinder

Comment by lolinder 4 days ago

18 replies

This is why I haven't switched my NixOS to flakes yet. The community discussions always act as though flakes should be the default that everyone should use now, but I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. So far so good—my system is far more stable than it was under Debian and I've yet to run into anything that didn't have an easy answer.

I have a suspicion that because the Nix community is disproportionately likely to contain early adopters, the general mood in the forums is less risk-averse than I am with my primary stacks.

sshine 4 days ago

> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason.

My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes.

They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individual packages to have their own flakes, nixpkgs can already be loaded as a flake.

FlakeHub tries to popularise flakes, but I don’t know if there is a flake discovery problem to solve.

Ekala Project is designing a poly-repo alternative to nixpkgs (ekapkgs) and they don’t embrace flakes.

So... Flakes have reached full maturity: a decentralised package format that has stalled its adoption status within the main Nix toolchain.

  • 0x457 4 days ago

    > My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes.

    I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them.

    Flakes aren't default due to political reasons.

    • nixosbestos 4 days ago

      Yeah, I am flabbergasted that anyone can claim flakes don't solve problems. And yet, every SINGLE WEEK some newcomer gets tripped up on channels, managing them, realizing the root's channels are different than users, realizing their channels are out of sync on their multiple machines, no posting their channel revision when they solicit help. Not to mention pure eval. Not to mention transitive dependency overriding.

      • sshine 3 days ago

        > I am flabbergasted that anyone can claim flakes don't solve problems

        Yes, that would be an outrageous claim! That is, of course, not what I said.

        Arguing that channels lead to more problems than flakes is a good argument in favour of adoption of flakes. But you can also abandon channels without adopting flakes.

        Which is what I said: flakes don’t solve any problems that can’t be solved without flakes.

    • jmholla 4 days ago

      > I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them.

      Can you share some examples of such problems?

      • 331c8c71 3 days ago

        With flakes I can get other people to run exactly the stuff I packaged with one command e.g. `nix run github:...` which can also be a reference to specific commit BTW.

        At this point I don't even quite remember what would be the sane alternative without flakes but I am happy to discuss...

      • 0x457 3 days ago

        1) Channels are hard to maintain (that's why overlays were introduced...)

        2) Overlays only solve issue of adding your own packages to an existing channel

        3) System channels and user channels are two different things.

        4) Many times I've updated my home-manager profile and forgot to update system profile and it borked due to channels being out of sync (user error, but flakes remove that foot gun)

        5) Very easy to have portable dev-env. If a system has nix installed, just typing `nix develop` in my repo would put you in the exactly same dev environment as me. In most cases it would byte for byte identical. I'm not going to tell you to install 100 of dependencies, not going to bother you with what application is written in, all you have to do to build it locally is to type `nix build .#`. I'm not even going to bother you how to run test because `nix check` will run them.

        6) Flakes provide some schema, you know here nixos or home-manager modules would be.

        7) Flakes are easy to compose together

        8) I can have identical env on CI, production and my local machine without any extra overhead - flake.lock takes care of this.

        All of this is extremely predictable: I got a new laptop, using nix-anywhere I've installed nixos on it, that had pretty much identical look and feel of my desktop. It all boils down to - channels suck and hard to use.

      • sshine 3 days ago

        I can say what I use flakes for at work:

        I have a repository with system configurations for some CI infrastructure: a build server, a test runner.

        The test runner can either be generated as an SD-card image using nixos-generators or live-updated using a remote `nixos-rebuild switch`. The OS configuration contains stuff about purposing specific motherboard GPIO pins.

        Both systems depend on custom software not in nixpkgs; these are just hosted in private git and have a flake that mainly provide a devShell, but also provide a cross-compiled binary.

        Flakes handle all of that in a predictable way: OS images, cross-compiled binaries, devShells, cross-repo linking, convenient hash-pinning.

  • SuperSandro2000 3 days ago

    Flakes bring you one interface to share common dependencies which is kot possible without an interface.

    • hamandcheese 3 days ago

      That interface could have been built in vanilla nix, though.

      Instead, a bunch of very useful features are bundled with flakes, like pure eval, eval caching, and git-awareness. But flakes still have some showstopping usability issues preventing users from benefiting from these great features. Issues like that it copies your repo root to the nix store on every evaluation, which scales terribly to bigger repos. Not to mention other issues like the extremely limited ability to override a flakes inputs - you can't pass a configured instance of nixpkgs for example.

      Generally speaking, the more advanced the use case, the more likely it is that flakes won't work well. Which probably helps explain why flakes are still unstable after so many years.

      • SuperSandro2000 3 days ago

        Everyone has some opinion. There are the people that say that flakes do to much and others are saying they do to little. No matter in which direction you go, someone is always unhappy.

        Eval caching depends on pure eval and pure eval was previously not possible because channels are by design the most impure and cursed thing and are just a bandaid that lasted way to long.

        The scaling with big repos gets worse as some use flakes instead of their normal build system which is not the intended use case. You still do development like normal with the normal build system.

        Flakes are still unstable because everyone wants something different and there are still breaking changes planned which then everyone would wine about and maintaining backwards compatibility is a pain if you still change fundamental things.

        • hamandcheese 3 days ago

          > Flakes are still unstable because everyone wants something

          Yeah, that is definitely true (as evidenced my complaints). I firmly believe the original sin of flakes was how many things it bundled together.

      • [removed] 3 days ago
        [deleted]
    • sshine 3 days ago

      Yes, they bring an interface.

      And lockfiles that are automatically maintained where digests are extracted into.

      Unlike if you do builtins.fetch* and pin those, in which case the digests end up in your source code.

ChocolateGod 3 days ago

I'm glad I'm not the only one who's grinding their gears with flakes.

I decided to migrate to flakes because a lot of the documentation for things I wanted to do with NixOS required flakes. It took me at least a few hours to understand what the purpose of them was though.

I just wish the documentation would be improved really, as an example https://nixos.wiki/wiki/Build_flags#Building_the_whole_syste... no longer works (gcc complains).

  • SuperSandro2000 3 days ago

    Be the change you want to see and help documenting the missing parts.

    Also that is the old wiki but the same stays in the new one.