This is certainly the usual, recommended approach.
It’s not the approach I tend to take ;)
If you modify dependencies, run: update-locks
My opinion of lockfiles is that they’re a hack, to manually work around problems with “legacy” systems like Gradle (scare-quotes, since Gradle came out after Nix but didn’t learn its lessons). In situations like this, I prefer to use import-from-derivation to generate those lockfiles with a fixed-output derivation, and take the hash as a function argument in the default.nix. Doing so has a few advantages:
No need to manually run separate commands (which is easy to forget)
Allows .jar dependencies to be overridden using function arguments (like a normal Nixpkgs definition); the generated lockfile will be different, so we just pass the different hash as well.
The only pitfall is that if we forget to pass a different hash: systems which have cached the old lockfile will use that instead, whilst those without will generate the new one and abort when its hash doesn’t match.
The way I avoid this is to calculate another hash for the name of that fixed-output derivation, e.g. "${pname}-${builtins.hashFile "sha256" patchedGradleFile}.lock". That way even if we forget to change the argument for our fixed-output hash, its name will not match anything in the cache (so it will reliably abort with a mismatched hash error).
I’ve done this in the past for projects written in Maven, Gradle and SBT (although the latter made it very hard to get anything remotely reproducible, so we switched those projects to Maven!)
This is certainly the usual, recommended approach.
It’s not the approach I tend to take ;)
My opinion of lockfiles is that they’re a hack, to manually work around problems with “legacy” systems like Gradle (scare-quotes, since Gradle came out after Nix but didn’t learn its lessons). In situations like this, I prefer to use import-from-derivation to generate those lockfiles with a fixed-output derivation, and take the hash as a function argument in the
default.nix. Doing so has a few advantages:The only pitfall is that if we forget to pass a different hash: systems which have cached the old lockfile will use that instead, whilst those without will generate the new one and abort when its hash doesn’t match.
The way I avoid this is to calculate another hash for the name of that fixed-output derivation, e.g.
"${pname}-${builtins.hashFile "sha256" patchedGradleFile}.lock". That way even if we forget to change the argument for our fixed-output hash, its name will not match anything in the cache (so it will reliably abort with a mismatched hash error).I’ve done this in the past for projects written in Maven, Gradle and SBT (although the latter made it very hard to get anything remotely reproducible, so we switched those projects to Maven!)