Ludovic Courtès writes: > Hi Alex, > > Alex Sassmannshausen skribis: > >> Ludovic Courtès writes: > > [...] > >>> I just had a bright idea (yes!): this can be addressed by writing >>> something like this in ~/.config/guix/channels.scm: >>> >>> (map latest-commit-with-substitutes-available >>> %default-channels) >>> >>> The hypothetical ‘latest-commit-with-substitutes-available’ would use >>> (git) and (guix ci) to find the latest commit for which substitutes of >>> interest are available, and would return: >>> >>> (channel >>> ;; … >>> (commit "cabbag3")) ;the ideal commit >> >> This sounds incredibly interesting — and it is testament once again to >> the power of Guix that this kind of solution could be feasible! > > Just to be clear: I don’t think this would be a substitute for a > “stable” branch; rather, I view as a way to have user-defined policies > such as “pull up to the latest commit for which there’s a substitute for > IceCat.” Ah, I understand now. So the example you provided is a user-defined policy to install the latest version of Guix that is downloadable using substitutes (if guix publish has published those already). As you say, in a similar vein, the end user could for themselves define a policy that searches for a commit containing a specific successful build, or a set of specific successful builds. >> Thinking this through in my head somewhat, I had the following thoughts: >> - This procedure is invoked client side, where the channel is defined >> - That means the git searching is done client side, on every invocation >> of guix (I guess this might be cacheable?) > > On every invocation of ‘guix pull’ only. That makes sense, and is way better than I feared :-) >> I have no idea what the performance cost would be. I guess you would >> use "guix weather" to turn the set of requested packages into a manifest >> which can then be checked with it. > > As I imagine it, the cost would be a few HTTP queries to the Cuirass > API. I should try to come up with an example to better explain what I > had in mind! Your example helps visualize this, thanks. Your example depends on there being a jobset that comprises the set of packages you are interested in testing. I imagine it is possible to do the same for an individual package / job. The situation would be different if the end user wanted to perform a similar operation for an arbitrary set of packages on their end. It would probably involve something like this (probably naive): (define (latest-commit-successfully-built-pkg pkg) "Return the latest commit for the pkg for which substitutes are (potentially) available." ;; Like your version, but magically performs query ;; for pkg, not the guix-modular-master evaluation (let* ((evaluations (latest-evaluations pkg)) (candidates (filter-map (lambda (json) (match (hash-ref json "checkouts") ((checkout) (cons (hash-ref json "id") (hash-ref checkout "commit"))) (_ #f))) evaluations))) (map (match-lambda ((evaluation . commit) (and (evaluation-complete? evaluation) commit))) candidates))) (any (match-lambda ((evaluation . commit) commit) (apply lset-intersection equal? ;; Like latest-commit-successfully-built, but takes an ;; individual package name for which we return the ;; commit (map latest-commit-successfully-built-pkg %set-of-packages)))) Obviously the larger the set, the more requests are required, and the lower the chance of a commit being available / a downgrade occuring >> The question of security updates is tricky at the moment already — I >> would hazard a guess that many people bail out of upgrading when they >> can't get substitutes for their entire profile / system right now, which >> means they are not getting security upgrades for package (a) when a >> substitute for (b) fails. > > That’s probably true, and I agree it’s problematic. > > What I typically do is “guix pull && guix package -n -u”. Then I look > at things that would be built; if, say, LibreOffice is among them, I > wait for a little while and try again later, until I can get enough > substitutes. That usually works okay, but it fails if it turns out that > one of the dependencies fails to build: substitutes never become > available in that case. Interesting. Do you think this kind of thing might be useful to have in the Guix manual? Like, in a section about a "typical" desktop end-user might manage their system day to day? Alex