NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
16.61k stars 13.09k forks source link

passthru.updateScript standardization #295028

Open ashkitten opened 7 months ago

ashkitten commented 7 months ago

Issue description

Automatic package update scripts are rather fragmented. We have several ways of updating packages:

Questions

Goal

Allow updating any auto-updatable package from a standard mechanism.

List of packages with non-standard update scripts:

nixos-discourse commented 7 months ago

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-11-28-nixpkgs-architecture-team-meeting-46/36171/1

jtojnar commented 7 months ago

I vaguely remember we discussed this topic in this repo but cannot find it now. Edit: I only found https://github.com/nixpkgs-architecture/issues/issues/17#issuecomment-1477098934


I think there are three distinct subjects here (although there is some overlap):

  1. Expression-level tooling
    • common-updater-scripts, especially update-source-version
    • shell scripts from *Updater (e.g. gitUpdater, unstableGitUpdater)
    • nix-update
    • random shell scripts specific to packages
  2. updateScript protocol
    • de facto standard, spearheaded by Rok, now documented in the Nixpkgs manual
    • compared to previous protocols like updateWalker, it does not try to encode policy, just points to an opaque script to run
    • Nixpkgs contains various helpers for creating those
      • *Updater family
      • gnome.updateScript
      • _experimental-update-script-combinators
      • nix-update-script using nix-update
  3. update runners
    • maintainers/scripts/update.nix – the official runner for updateScript protocol
    • nix-update – both low and high level tool, includes some baked-in policies
    • nixpkgs-update – also high-level, run by bot

maintainers/scripts/update.nix calls passthru.updateScript, but is underdocumented

The documentation is part of its help page (displayed when run without arguments). I have been thinking about folding it into the Python script for better UX of the argument handling.

How do we handle multiple packages that need to be updated together (i.e package sets)?

For GNOME, we use the predicate mode of update.nix but the predicate is currently ugly due to lack of tags.

I also want to implement update ordering (e.g. topological order in the dependency relation for packages that update together and require bumping of dependency, and reverse order for minimizing rebuilds when traversing the branch).