Hello Dariqq, Dariqq <[email protected]> writes:
> Hi Tomas, > > I have some custom updaters (e.g. a generic ftp-updater that is just a > reskinned > gnu-ftp updater but accepting any package with a ftp url and > ftp-server/ftp-directory property and one that parses an rss feed) > > The way to do that is a bit unconventional and relies on how guix uses the > guile > module system. I guess it is undocumented for this reason because it feels not > intended to be extended by channels. however it works if you accept quirks. > > On 29/10/2026 20:47, Tomas Volf wrote: >> Hello, >> for software packaged in my channel (legacy node versions in this case), >> I want to write an updater, so that I can handle all necessary updates >> just by running `guix refresh -u'. However I did not manage to find any >> documentation pertaining to this topic. >> Would anyone be able to advice on how to: >> 1. Write new updater. >> 2. Hook it into `guix refresh' so that it can be selected by -t? >> > > 2: There is the %updaters variable which looks at all (public) > upstream-updaters? variables in the (guix import) module hierachy. > > Probably using that guix "namespace" is slightly abusing the guile module > system > and how guix uses it for channels. > > Note that it currently uses the guix/import modules from the current profile > so > for testing it is easier to have it in your guix checkout to get it to do what > you want and then copy it into your channel once you are happy with it. This > is > another indicator that is is a bit of a hack. I discovered that when built from source, Guix will pick-up updaters in other channels when made available by -L. So I can develop the code in my channel, and test it using: --8<---------------cut here---------------start------------->8--- ./pre-inst-env guix refresh -L ~/my-channel my-package --8<---------------cut here---------------end--------------->8--- So no copy&pasting needed. > > For a bit less of a hack there is package-latest-release in (guix upstream) > which you can pass your own custom updaters list but then you need to add the > logic from (guix scripts refresh) to update the package inplace yourself. > > 1: > > An updater has a predicate that will get the package in question and > determines > whether it knows how to update that "kind" of package (usually based on url > and/or pacakge-properties) > > Second thing is the import procedure that will get passed the old package (and > potential target version and partial-version?) arguments and either returns #f > or a upstream-source record of the found version. > > For inspiration look at gnu-maintenance.scm where the hmtl and gnu updaters > are > defined which are somewhat understandable. > > If you fetch data look at (guix http-client) and http-fetch/cached and then > extract what you want but that depends on how the package provides the info. This is neat. I was able to fit updater (which checks signature of the tarball) for my variant of curl package into 59 lines including module commentary and #:use-module lines. >> Thanks, >> Tomas >> > > I hope this is useful, Yes, very. Thank you ^_^ Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
