nixpkgs-update icon indicating copy to clipboard operation
nixpkgs-update copied to clipboard

Integrate other package updaters

Open matthewbauer opened this issue 8 years ago • 7 comments

It would be really cool if we could integrate a few other package updaters into nix-update. We have a couple of different manual package updaters being run regularly. Usually people are good at doing this regularly but it definitely increases Nixpkgs' bus factor. Automating this process through nix-update could be very helpful. Here's my initial list along with the maintainers:

  • [ ] MELPA and ELPA updaters /cc @mdorman @ttuegel
  • [ ] Hackage updaters /cc @peti
  • [ ] NPM updaters /cc @svanderburg

Some other packages also have "update.nix" that might be possible to use. This was initially done by @garbas "update script" but I'm not sure if it's still actively being maintained.

matthewbauer avatar Mar 15 '18 19:03 matthewbauer

@matthewbauer please remove update.nix if you are able to migrate those packages that use it. having one way to do things can only be a good thing.

garbas avatar Mar 17 '18 21:03 garbas

We are using update.nix extensively for GNOME package set. I migrated to it from a custom shell script that we used previously, and added some fixes to it.

Another update system is updateWalker not sure how maintained is that.

jtojnar avatar Mar 30 '18 21:03 jtojnar

updateWalker looks promising. I'm experimenting with running it in Travis as a cron job.

Also for update.nix stuff, is there any way to pass a description of what's been changed? Something that could go in a commit and PR message hopefully. I guess we could do something like "$attr: $oldVersion -> $newVersion" for each attribute- not sure if all updaters will change the version though.

matthewbauer avatar Mar 30 '18 22:03 matthewbauer

Unfortunately, update.nix is quite limited. It does not even know if the package was updated at all. Single updateScript to take care of everything is nice helper for manual updates but does not really fit into more automatic workflows.

I was thinking about adding simple signalling through exit statuses and maybe some structured output but that would just be cumbersome.

Ideal solution would be multiple scripts directed by update.nix, each taking care of a separate phase – fetch versions, choose a version based on a stability criteria, obtain a changelog, fetch source, update an expression. If I recall correctly, that is what updateWalker does. Maybe we could brush it up (it felt somewhat antiquated to me, last time I looked into it).

Edit: update.nix supports creating commits now.

jtojnar avatar Mar 30 '18 23:03 jtojnar

Does this https://github.com/NixOS/nixpkgs/pull/100772 give testimony of an effective inclusion of passthru.updateScript?

This update was made based on information from passthru.updateScript.

blaggacao avatar Oct 21 '20 03:10 blaggacao

initial support was given in https://github.com/ryantm/nixpkgs-update/pull/205

jonringer avatar Oct 21 '20 03:10 jonringer

This can be closed right?

As soon as the updaters wire themselves up into passthru.updateScript, they should "just work" with nixpkgs-update.
That'd make the last leap a Nixpkgs issue.

Atemu avatar Nov 02 '22 11:11 Atemu