IRC channel logs

<PurpleSym>rekado: Do you update changed inputs by hand?

<rekado>PurpleSym: yes. But the updater tells me what changes I should consider.

<PurpleSym>Any reason why these are not applied automatically? I was thinking this could help with Haskell updates.

<PurpleSym>(As well as automated updates to #:cabal-revision)

<rekado>the low-hanging fruit was to run the importer when refreshing; then we diffed the new and the old; nobody worked on applying the changes automatically.

<rekado>but: there are a *lot* of suggestions that I ignore because I know these packages

<rekado>it would be annoying if I had to undo them all, so we would need some sort of property which could encode overrides

<rekado>or warnings

<rekado>one example: R packages that wrap JavaScript libraries — r-dt.

<rekado>it has lots of JS inputs that the importer cannot make sense of, so it recommends deleting them all.

<rekado>what I’d really want it to do, though, is to print a reminder that this package contains minified JS and I should check that I’ve taken care of each of the minified files.

<rekado>now that I’m doing everything manually anyway I get to check each package that wraps JS.

<rekado>currently we use mere comments to warn those who read the code.

<rekado>would be nice if we could have a mechanism to override suggestions and print messages on refresh.

<rekado>then I’d be happy to see more automation.

<PurpleSym>r-dt looks like an unusual special case. But yeah, some kind of annotation would be required for undeclared dependencies.

<PurpleSym>I don’t think running the importer again when refreshing is necessarily a bad thing. I was trying to move description and synposis to from the old package over to the newly imported one and completely overwrite the old package yesterday, but can’t figure out how to do that.

<rekado>we *are* running the importer again when refreshing. But we don’t replace the whole package definition. We just pick inputs and compare them.

<rekado>if r-dt is a bad example: r-xfun is another. It cannot add r-knitr to the inputs, because of a dependency cycle.

<rekado>there are also packages that need r-r-rsp for vignettes, but the importer doesn’t know that.

<civodul>'guix refresh' could/should update the inputs fields IMO

<rekado>with R packages there’s also a conflict between propagated-inputs and regular inputs; rmarkdown, for example, should propagate pandoc and not just have it as a regular input

<rekado>usually there are about two dozen suggestions that I ignore.

<rekado>maybe more

<rekado>for 630 updates that’s not a lot, but it would be very annoying if I had to go back and fix these automatically borked packages.

<rekado>PurpleSym: we often fix the descriptions of R packages, so I’d like to not have them automatically replaced with whatever has been imported.

<rekado>though some of that fixing could be automated, too

<rekado>(e.g. dealing with quoting, URLs, DOIs, citations, etc)

<civodul>rekado: we could annotate packages that should be ignored?

<civodul>ignored as in: whose inputs should not be modified upon "guix refresh"

<rekado>yes, that’s what I proposed above

<civodul>ah alright, sorry

<PurpleSym>rekado: Yeah, that’s what I meant: Keeping the old description/synopsis, but using inputs/arguments/… from the fresh import.

<PurpleSym>I’m afraid my knowledge about Scheme is not deep enough to write the code for that though ☹️

<civodul>there's code from 'guix style' that may be handy here

<civodul>"guix style -S inputs" modifes inputs fields surgically

<PurpleSym>SIMPLIFY-INPUTS you mean?

<civodul>yes

<civodul>well that one is quite intimidating actually

<rekado>PurpleSym: we also have code that may be useful in etc/committer.scm

<civodul>but it does more than needed

<civodul>oh right

<civodul>also the "reimporter" i wrote: https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00297.html

<civodul>we need to put the pieces together :-)

<PurpleSym>Thanks, I’ll look at those too.

<rekado>I have a manifest here to build modern Python packages with an older version of Python: https://elephly.net/paste/1653945439.scm.html

<rekado>unfortunately, this doesn’t quite work the way I want it to.

<rekado>I only care about the python-* packages to be rebuilt.

<rekado>I don’t want to use these modified Python packages as inputs to, say, glib or dbus.

<rekado>I suppose I may need to define independent variants of these python-* packages instead.

<civodul>at first sight use-old-python LGTM

<rekado>adding an extra (negate python-package?) as the CUT? argument to package-mapping improves things a little

<rekado>but it still leads to a rebuild of librsvg and gtk+

<rekado>I suppose I really do want to have more than one variant of the transformed packages

<rekado>I want the transformed package when it ends up in the profile, but I want the regular variant when it builds packages that are unrelated to python (and merely have Python or python-* as inputs).

<rekado>looks like the package transformations operate under the assumption that only *one* variant should exist — either the transformed or the original.

<rekado>so I guess what I need to do is define new package variants for all the packages I care about (and their Python inputs) and then just build those

<rekado>instead of telling Guix to *rewrite* the graph

IRC channel logs

2022-05-30.log