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

Post by esjeon » Sun, Aug 13, 2023, 7:17 AM UTC

eternityforest wrote: post #66

sourcegrift wrote: post #53

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 rea…

It's kind of scary because Nix is one of the coolest concepts for how to manage Linux systems... Most everything else has so much baggage from things that were designed around hand-maintained, non-disposable installs. But the community does seem to be still tinkering focused. I miss the early 2000s when even the hackers seemed to want to make their stuff easy to use(although my source for that is I saw a screenshot o…

Post by kaba0 » Sun, Aug 13, 2023, 7:23 AM UTC

packetlost wrote: post #46

_hl_ wrote: post #37

Earlier quoted context omitted.

> Building third party flakes takes forever since every flake uses its own version of nixpkgs. The “official” (as in, community consensus) solution seems to be to bring your own nixpkgs, and manually override the nixpkgs of every dependency (and their transitive dendencies) and verify your build still works. Which just doesn’t seem right to me. Flakes are great for building an ecosystem of composable, reproducable so…

The traditional way is to reduce the surface area of the core package as much as possible, such that it sees less changes/releases overall. The way I would do it with nix is: because everything gets hashed, just check that the built output with a new nix-pkg version matches the hash with the old version and fail out/fetch the older version as a second step. The rest is just finding ways to cache that build fail infor…

Post by lloeki » Sun, Aug 13, 2023, 7:32 AM UTC

pkulak wrote: post #13

bongobingo1 wrote: post #8

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 syst…

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?

Post by eternityforest » Sun, Aug 13, 2023, 7:37 AM UTC

esjeon wrote: post #82

eternityforest wrote: post #66

Earlier quoted context omitted.

It's kind of scary because Nix is one of the coolest concepts for how to manage Linux systems... Most everything else has so much baggage from things that were designed around hand-maintained, non-disposable installs. But the community does seem to be still tinkering focused. I miss the early 2000s when even the hackers seemed to want to make their stuff easy to use(although my source for that is I saw a screenshot o…

> But the community does seem to be still tinkering focused. Because Nix does NOT make packaging easier. Maintainers are the ones who create distros, and they can live a happy life with something as crude as PKGBUILD, since build instructions are almost always stable. Even for users, most of them just don't need to juggle with package versions. Bleeding edge is mostly covered by Arch and package pinning works ridicul…

Post by sullyj3 » Sun, Aug 13, 2023, 7:39 AM UTC

jsomedon wrote: post #7

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.

    { pkgs ? import  {} }:
      pkgs.mkShell {
      # ...

    devShells.${system}.default = import ./shell.nix { inherit pkgs; };