Hacker News Reader

This is good constructive criticism and I'd like to second every part of it.

You're probably already aware, but for the benefit of newcomers in this thread, here's a link to the massive PR trying to work out more efficient copying of local flakes to the Nix store:

https://github.com/NixOS/nix/pull/6530

A few dedicated folks are working really hard to break that thing down and test it and get it merged. I can hardly wait!

>You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding

This is decidely not quite true. You must have the file visible to Git. Flakes still just uses the files, as long as they're tracked by git. As long as you have no new files that aren't in the index, staging unstaged changes will not change eval.

That said, yes, when you add a new file to a flakes repo, you start to develop a habit of always adding it to the stage/index for eval.

but you should ONLY ever see this as a very very obvious "file not found", it is not a subtle problem as this post implies.

I concur, this has not been something I've tripped up on. It's pretty obvious when it's the problem.

> 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 software. The more they succeed at that, the bigger the problem becomes. Surely it’s not too late to figure out a principled solution before stabilizing flakes?

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 information so that you can share the result across users transparently.

There is work on content-based hashing, but that is not only related to flakes. So that problem may get solved, and is likely the correct path forward.

I think the current solution is not too far from an ideal scenario: package the most commonly used dependencies/programs in nixpks (roughly what would be available with other package managers’ default channel/repository), and use flakes as an out-of-tree solution for proprietary/freemium/hard-to-package/very specialist software, similarly to what you might use Docker for.

That way you get the benefit of a minimal-sized system with no size overhead for the most part, yet out-of-tree git repos get reproducible at any commit, and it is even easier than adding a new repo to apt, etc.

With content-addressable hashing, the problem may largely solve itself, reusing unchanged dependencies between older flakes.

This depends, Hyprland has their own flake, and rather than overriding nixpkgs they recommend adding their cachix binary cache. You get binaries for Hyprland from Cachix and for it's dependencies from cache.nixos.org.

Works well for me. Though when doing configuration changes I usually pass --no-substitutes (or smth) to not query all my subs for derivations that'll never be in a remote cache.

> Building third party flakes takes forever since every flake uses its own version of nixpkgs.

That's not quite right. It may use a predefined version of nixpkgs and there may be a reason the version is hardcoded to something. But if that's not what you want, you can use something like `nix run ... --override-input nixpkgs nixpkgs` and it will run with your current system nixpkgs version instead.

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

There's an upside to this: I've been in situations where I've lost the definition of a previous configuration because I didn't check the state of it at that point into source control. By "forcing" the user (me) to at least add the current state to source control (if not commit it), it makes it more likely for me to have the configuration/definition for the state saved at the same time as the state itself.

If you don't lose the whole repo, you can probably pull those versions of of the git reflog even if you do lose them. One of the blessings of having `git add`ed something.

FYI, if you want Flakes to not be tied to Git, I'd recommend using `nix [...] path://$PWD` or something along those lines. This will bypass the VCS detection for you.

Given that the Git thing is meant to stop you from shooting yourself in the foot, I think maybe it's time to conclude it wasn't really that great of an idea. However, I still see why it works that way.

This makes the third issue of the parent comment much worse, unfortunately since there will be a new /nix/store hash when even things in .gitignore or things like lock files or editor backup files are touched. I've cleaned up hundreds of gigs after a long evening of hacking

I used to be annoyed by how Flakes are coupled to Git, but I've realized that dealing with that is way less pain than dealing with builds that accidentally depend on non-version-controlled files. Missing an unstaged file is annoying, but it gives you an explicit error message and it's easy to fix; accidentally depending on a wrong file can skate by silently (perhaps leading to extra rebuilds but nothing more) until you try to reproduce the build somewhere else, and then it's at least a small headache to debug and fix.

Well, not necessarily. There’s a `follows` argument to pin through the different dependencies. It’s not ideal but it’s there.

> Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding.

You only need to `git add` the file once.

You do not need to stage every change after that before flakes can "see" the change.

Yes, you are right - I misremembered this detail. My problem at the the time was I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons). So I had to unstage and restage it every time I created a new commit.

> I didn't want to commit my flake.nix to the repository in one of my previous work places (for political reasons).

Does the same workplace not allow people to include config related to their editors and so on?

Even better, you can `git add -N` and just record the intent to include the file in a later commit, without staging its current contents. Nix seems happy with that.

> 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

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.

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.

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

That's what flake.lock is for, it remembers the versions picked. No need to put versions in the flake urls just for that.

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

then what's the point of using nix and flakes if flakes destroy the very point of nix, reproducibility?