<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>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