Allow nix to update wrong hashes

[nomeata]

Love using nix. But one of the most annoying things about it is updating the various hashes of fixed-output derivations (including fetching tarballs, git checkout, SVN etc.)

What I do (and I believe that is the usual thing to do) is that I update the source (URL, revision etc.), and change a random character in the hash string literal, run nix-build, look at the error message, copy’n’paste the actual hash, put it back in the .nix file, and re-run nix-build.

Assuming I am not the only one that is annoyed by this, I would like to propose the following remidy, in two steps:

1. nix adds meta-data to those strings that come directly from string literals in a source file the location (filename, row, column) of that string literal, e.g. by adding fields to the string struct in Value.hh. For calculated strings (results of concatenation etc.) no information is stored.

   This already allows nix-build to provide better error messages: Instead of just printing the expected and actual hash, it can precisely tell the user which has they have to update.

2. nix-build gets an additional paraeter --update-hash, and when nix encounters such a hash mismatch, and the expected hash has location data attached, and if some sanity checks pass (the given file exists, is writeable, and the given location is actually a the mentioned string literal), it simply updates the hash and continues building.

   For even more convenience, we could also let nix-build, even without a flag, notice that it is attached to a terminal, and upon a hash mismatch, ask the user “do you want me to update the hash for you [Y/n]?”

I know that for specially prepared nix derivation, e.g. those that store the GitHub data in a Json file, there is a separate tool to update these. But that only applies to a fraction of the hashes, and still requires extra steps.

[stale]

I marked this as stale due to inactivity. → More info

[nomeata]

I’d still like this feature (although I must admit that niv has made it less direly needed)

[bjornfor]

https://github.com/Mic92/nix-update looks nice!

[nomeata]

yup, and tools like niv help too. But if I am not mistaken, all these tools are specialized to a certain pattern of importing sources (e.g. knows that the cargoSha256 field contains a hash).

What I am proposing here is a more fundamental and general solution that works no matter where in your nix files the string literal with the hash is stored, and no matter how many layers of abstractions are between the literal and where it is used.

OTOH, maybe this is better implemented via a tool like https://github.com/nvbn/thefuck that parses the error message and then just runs a blunt sed -i -e s/old_hash/new_hash/ **/*.nix in the current directory :-D

[edolstra]

One solution is to treat all external source dependencies as flake inputs. That way they can be updated in a uniform way by running nix flake update. The only thing missing for this is a flake input type that allows specifying how to find the latest version of a package.

[nomeata]

Again, that’s a narrow solution to the problem that applies when tracking dependencies (and there, I am personally very happy with https://github.com/nmattia/niv, with featurs like NIV_OVERRIDE_foo=/path envvars and tools dfinity/motoko#2258 (review)). but it doesn’t work well for, say, a cargoBuildPackage-style dynamically created dependency vendor directory hash (does it?).

[stale]

I marked this as stale due to inactivity. → More info

[KiaraGrouwstra]

OTOH, maybe this is better implemented via a tool like https://github.com/nvbn/thefuck that parses the error message and then just runs a blunt sed -i -e s/old_hash/new_hash/ **/*.nix in the current directory :-D

@nomeata https://codeberg.org/kiara/cfg/compare/3e7efd27b05b0fe35ae304b52e1247f7593c37b3...fuck-hash