IRC channel logs
2025-06-04.log
back to list of logs
<flypaper-ultimat>Kabouik: btw, i wrote a thing that looks up the right guix-cran / guix-bioconductor commit for the a given guix commit <civodul>Kabouik: yup, curious to learn more about it! <civodul>(i’m on the R-R network with other Guix folks) <flypaper-ultimat>usage: "./channel-solver --use-cran --use-bioc GUIXCOMMIT" where guixcommit is a long commit id in guix, will create a channel listing that uses the guix-cran/guix-bioc commit "closest" to GUIXCOMMIT. <flypaper-ultimat>(closest = the most recent cran commit that specifies it uses that guix commit or a precursor of it ) <civodul>but i’m curious: it looks interesting :-) <flypaper-ultimat>it walks the commits of guix-cran/guix-bioc and '(read)'s the channel structure thats in the commit message, and then checks (graph-descendant? ) on the guix repo for the user specified commit and channel-listings commit <flypaper-ultimat>guile-git was actually very easy to use. yay for 'fold-commits' and 'graph-descendant?' <flypaper-ultimat>the main use-case is like the one of kabouik, where you know a guix-commit that you want to use, because you looked at e.g. data-services and saw that a certain guix commit matched your fancy because you wanted e.g. R@4.2.2, but then you also want to use some packages from these automatic channels, how do you 'align' the automatic channels to guix. <flypaper-ultimat>but it wouldnt work right now for e.g. guix-science because the guix that it assumes. <flypaper-ultimat>so yeah, mostly for people trying to 'revive' their old (non-guix-recorded) projects with guix. <civodul>generally there seems to be a need, or a perceived need, for mapping from version numbers of channel commits <civodul>perceived need primarily for people coming from other deployment tools <civodul>i guess someone who already uses Guix is likely to record their channels <flypaper-ultimat>because other deployment tools make people think that a version number uniquely specifies a program. <flypaper-ultimat>but the version _does_ specify the interface; so i can imagine that if you directly use r-somepackage@x.y.z in your old (non-guix-recorded) analysis and with people not following semver, you'd want that to be the same. <flypaper-ultimat>ah, completely forgot about the guix-git-log. Yeah, actually this version lookup thing is something i've been discussing for a 'guix starter kit for R', besides being an an easy setup, could possible help 'revive' old non-guix-recorded projects. (even though the environment wont be the same as the non-guix environment, it would at least be runnable) <flypaper-ultimat>civodul: guix-git-log as it is now, would not be informative for e.g. guix-cran, because its commit message is not indicative of what changed. Only by looking at scheme code in the patch file / commit can you determine what changed. the data service does indeed capture more information because it works with realized guix environments, but am I correct it only captures info on guix commits where the build farm actually ran? <flypaper-ultimat>i.e. is the following statement correct? if a series of commits a through f was all pushed to master in a negligable time, the build farm would run at 'f' (and not at a..e ), and if a package's version field would change at commit 'c', the dataservice would record the derivation as changed at commit 'f' ? <civodul>flypaper-ultimat: oh you’re right: ‘guix git log’ would only be useful for Guix proper <civodul>i was thinking of the more general case of mapping package versions to commits <flypaper-ultimat>yeah, so a thing that i think would work for the R case, (but not so much for the general case, for packages that are created as a result of functions), would be to walk the commits, walk the f the files that changed with (read), and if we encounter a package structure, find its name and version field, and if that is different than recorded in a more recent commit, record that version, package name and commit into a database. <flypaper-ultimat>but that would only work for packages that are kinda 'statically' defined. (and there'd have to be some special case handling for (git-version ...) ) <flypaper-ultimat>(using (read) so that we dont have to instantiate a guix for every commit that we want to consider) <flypaper-ultimat>or, just philosiphizing, could we somehow start a guile session in old commmit, see what objects would be changed in the next commit, stash those, live load the next commits files, and then compare objects ? and this way move forward in time without having to build a profile for each commit? <civodul>flypaper-ultimat: that’s possible but expensive; ‘guix pull -N --details’ can do something like that (it shows new/upgraded/removed packages) <flypaper-ultimat>yeah, but that needs to eval the entire package list for both generations right (and start an inferior for both ?). what if we only re-eval the file(s) that changed in the commit, in the same guile session. so the maximal subset (in each commit) that we need to compare is the exposedd symbols of that specific module. Or are you saying this entire procedure is also expensive / memory usage will balloon as we move (forward / backward) <flypaper-ultimat>through time? Not that familiar with the guile internals though, so i dont know how this would be either. <civodul>flypaper-ultimat: yes, it runs both generations and compares the package sets pairwise