Nix-update updates versions/source hashes of nix packages. It is designed to work with nixpkgs but also other package sets.
| Feature | Details |
|---|---|
| Detect latest version automatically | BitBucket, Codeberg, crates.io, Gitea, GitHub, GitLab, npm, PyPi, RubyGems.org, Sourcehut, Savannah |
| Rust | buildRustPackage's cargoHash/cargoSha256/cargoLock and cargoSetupHook's cargoDeps |
| Go | buildGoModule's vendorHash/vendorSha256 |
| npm | buildNpmPackage's npmDepsHash and npmConfigHook's npmDeps |
| pnpm | pnpm.fetchDeps' pnpmDeps |
| PHP | buildComposerProject's vendorHash |
| Maven | buildMavenPackage's mvnHash |
| Elixir | mixRelease's mixFodDeps |
| Yarn | fetchYarnDeps' offlineCache output hash |
| Zig | zigDeps output hash |
| .NET | nugetDeps |
| Custom dependency hashes | see --custom-dep |
| Update flake outputs | see --flake |
Generate lockfiles (Cargo.lock, package-lock.json) |
see --generate-lockfile and --lockfile-metadata-path |
| Build and run the resulting package | see --build, --run or --shell |
| Commit updated files | see --commit |
Run update scripts (passthru.updateScript) |
see --use-update-script |
| Run package tests | see --test |
| Review the update with nixpkgs-review | see --review |
| Format the changed expression | see --format |
| Specify the system to use | see --system |
nix-update is included in nixpkgs.
To run without installing it, use:
$ nix-shell -p nix-updateTo install it:
$ nix-env -f '<nixpkgs>' -iA nix-updateTo run it from the git repository:
$ nix-build
$ ./result/bin/nix-updateIf you have nix flakes enabled you can also do:
$ nix run github:Mic92/nix-updateFirst change to your directory containing the nix expression (Could be a nixpkgs
or your own repository). Then run nix-update as follows
$ nix-update attribute [--version version]If your package is defined in a flake use the --flake flag instead:
$ nix-update attribute --flake [--version version]nix-update will then try to update either the
packages.{currentSystem}.{attribute} or {attribute} output attribute of the
given flake. To update a package in legacyPackages, pass the full path to that
package including the platform: legacyPackages.{platform}.{attribute}.
This example will fetch the latest github release:
$ nix-update nixpkgs-reviewIt is also possible to specify the version manually
$ nix-update --version=2.1.1 nixpkgs-reviewTo update an unstable package to the latest commit of the default branch:
$ nix-update --version=branch nixpkgs-reviewTo update an unstable package to the latest commit from a certain branch:
$ nix-update --version=branch=develop nixpkgs-reviewTo only update sources hashes without updating the version:
$ nix-update --version=skip nixpkgs-reviewTo extract version information from versions with prefixes or suffixes, a regex can be used
$ nix-update jq --version-regex 'jq-(.*)'By default nix-update will locate the file that needs to be patched using the
src attribute of a derivation. In some cases this heuristic is wrong. One can
override the behavior like that:
$ nix-update hello --override-filename pkgs/applications/misc/hello/default.nixThe nix-update command checks for new releases of a package using the src
attribute. However, in some cases a package may use a non-standard release URL
that is not supported by nix-update, but still has a repository with release
information. For example, the Signal Desktop package in Nixpkgs fetches updates
from https://updates.signal.org/, but also publishes release information on its
GitHub page. In such cases, use the --url parameter to direct nix-update to
the correct repository:
nix-update --url https://github.com/signalapp/Signal-Desktop --override-filename pkgs/applications/networking/instant-messengers/signal-desktop/default.nix signal-desktopWith the --shell, --build, --test and --run flags the update can be
tested. Additionally, the --review flag can be used to initiate a run of
nixpkgs-review, which will ensure all
dependent packages can be built.
In order to ensure consistent formatting, the --format flag will invoke
nixfmt (nixfmt-rfc-style in nixpkgs).
# Also runs nix-build
$ nix-update --build nixpkgs-review
# Also runs nix-build nixpkgs-review.tests
$ nix-update --test nixpkgs-review
# Also runs nix-shell
$ nix-update --shell nixpkgs-review
# Also runs nix run
$ nix-update --run nixpkgs-review
# Run `nixpkgs-review wip` to validate dependent packages
$ nix-update --review nixpkgs-review
# Format file
$ nix-update --format nixpkgs-reviewNix-update also can optionally generate a commit message in the form
attribute: old_version -> new_version with the applied version update:
$ nix-update --commit bitcoin-abc
...
[master 53d68a6a5a9] bitcoin-abc: 0.21.1 -> 0.21.2
1 file changed, 2 insertions(+), 2 deletions(-)By default, nix-update will attempt to update to the next stable version of a
package. Alphas, betas, release candidates and similar unstable releases will be
ignored. This can be affected by changing the parameter version from its
default value stable to unstable.
$ nix-update sbt
Not updating version, already 1.4.6
$ nix-update sbt --version=unstable
Update 1.4.6 -> 1.5.0-M1 in sbtNix-update can also run the passthru.updateScript defined by the package.
$ nix-update sbt --use-update-scriptArguments can be passed to nix-shell maintainers/scripts/update.nix like so
$ nix-update sbt --use-update-script --update-script-args "--argstr skip-prompt true"In case your package has dependency fetchers with custom attribute names, you
can pass them using --custom-dep:
$ nix-update openmetadata --custom-dep yarnOfflineCacheUi --custom-dep yarnOfflineCacheUiCore
Some packages consist of multiple fixed-output derivations derived from the same upstream source. For example, a Go project with Go module dependencies might also include a JavaScript project with npm dependencies.
To support such use cases, nix-update allows specifying subpackages directly
in the command line. Consider a package accessible via the some-package
attribute, which also provides a second fixed-output derivation as a subpackage
named web-ui:
{
buildGoModule,
fetchFromGitHub,
buildNpmPackage,
}:
let
pname = "some-package";
version = "1.0.0";
src = fetchFromGitHub {
owner = "owner";
repo = "repo";
rev = "v${version}";
hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};
web-ui = buildNpmPackage rec {
...
npmDepsHash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};
in
buildGoModule rec {
inherit
web-ui
pname
version
src;
vendorHash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
preBuild = ''
cp -r ${web-ui}/* web/dist
'';
passthru = {
inherit web-ui;
};
}Note that you must add the subpackage to passthrough in order for nix-update
to be able to access it.
You can update the package and its subpackage using nix-update as follows:
nix-update --subpackage web-ui some-package
The --subpackage option can be repeated to update multiple subpackages in the
same derivation.
First clone the repo to your preferred location (in the following, we assume
~/ - your home):
$ git clone https://github.com/Mic92/nix-update/ ~/git/nix-updateThen enter the dev shell:
$ cd ~/nix-update
$ nix developChange to the repository that contains the nix files you want to update, i.e. nixpkgs:
$ cd nixpkgsNow you can run nix-update just by specifying the full path to its executable
wrapper:
$ ~/git/nix-update/bin/nix-update --commit helloThis project uses treefmt-nix for formatting. It can be run on the repository like that:
$ nix fmt
- create pull requests
nix-update might not work correctly if a file contains multiple packages as it performs naive search and replace to update version numbers. This might be a problem if:
nameis used instead ofpnameand/or${version}is injected intoname.
Related discussions:
- nixpkgs-update is optimized for mass-updates in nixpkgs while nix-update is better suited for interactive usage that might require user-intervention i.e. fixing the build and testing the result. nix-update is also not limited to nixpkgs.