Ludovic Courtès writes:
> Hi Alex,
>
> Alex Sassmannshausen <a...@pompo.co> 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
