How do you make sure that flake.lock gets updated?

Help
1

I’m starting to use flakes for the first time. I understand that I need to run nix flake update every so often or else my inputs won’t get updated. Here’s my question: how do I make sure that I remember to run nix flake update? Do you guys have any tools or tricks that you use to make sure that you don’t forget?

2

School of hard knocks? Sometimes I don’t want to update the inputs because e.g. some packages on the current nixpkgs rev might be broken, so it’s always a conscious decision for me.

1 Like
3

There’s this…

2 Likes
4

update-flake-lock does look like a good option, but it depends on GitHub, and not all of my repositories are on GitHub. I also prefer to not rely on centralized services.

I ended up creating a pre-commit hook called flake-lock-updater. You can use it by adding this to your .pre-commit-hooks.yaml file:

repos:
    -
        repo: https://github.com/Jayman2000/jasons-pre-commit-hooks
        rev: 0edc448903d6fa92d5c5df9da9f55bd028c53058
        hooks:
            - id: flake-lock-updater

Before every commit, flake-lock-updater will look at any flake.lock files that are in your repo. If any of those flake.lock files contains a "lastModified" value that’s older than 1 week, then flake-lock-updater will automatically run nix flake update. If nix flake update ends up changing any files, then it will abort the commit in order to give you a chance to git add the new flake.lock file.

5

That workflow sounds like it would encourage mixing in input bumps with commits that never intended to include them.

2 Likes
6

I never thought of it like that. In practice, I always create a separate commit in order to fix any pre-commit errors, but I see how someone else might get lazy and just put everything into one big commit.

Do you have any suggestions for how I could improve this workflow?

7

If you want to make sure that something happens at some frequency, automate it.

Or at least automate a reminder to yourself to do it manually.

Coupling it with anything else, seems unreliable to me.

8

If you want to make sure that something happens at some frequency, automate it.

Or at least automate a reminder to yourself to do it manually.

Does my pre-commit hook count as automating it or automating a reminder to myself?

Coupling it with anything else, seems unreliable to me.

Why does coupling it with something else seem unreliable to you?

9

What if you don’t work on it for a while?

10

If I don’t work on a project for a while, then the flake.lock file won’t get updated. For most of my projects, I actually think that this is a good thing. For most of my projects, I only use a flake to provide a dev shell for working on the project. If no one is working on the project, then no one is using the dev shell so there’s no need to update it.

That being said, I am currently working on creating new NixOS configs that use flakes. For that project in particular, it would be bad if I stopped updating its flake.lock file. I guess I’ll have to create a systemd service that sends me update notifications or something.

1 Like
11

For me, sudo nix flake update followed by sudo nixos-rebuild switch is the way I update my system. It is a conscious decision. If I forget the first command, nothing gets updated in the second command, and it’s fairly obvious.

Sometimes I only want to run the second command such as when I make a config change and I’m not interested in updating packages at the same time. Other times, I am only interested in updating packages and that’s when I run both.

12

I would suggest not running this as root, it can break permissions on files especially in git repos

13

Good point. Force of habit. In my case, it doesn’t actually break permissions because flake.lock already exists so it’s just an edit. But yeah, sudo isn’t necessary.

14

Renovate also supports flake lock file updates. So it is an alternative for any platform that supports that.