Re: Google Summer of Code 2023 Inquiry

[Kyle <kyle@posteo.net>]

>I do not know what you have in mind with “working satisfiable
>configurations” or with “a variant of the solver”.  To my knowledge,
>this implies some SAT solver.  Well, before going this direction, I
>would suggest to read some output of the Mancoosi project [8].
>Especially this part [9].  From my point of view, the direction “working
>satisfiable configurations” or “a variant of the solver” would break the
>reproducibility of a specific configuration for the general case.  Part
>of the problem about computational environment reproducibility is
>because package manager implements solvers for installing some packages.

Yeah, we definitely don't want a solver for instantiating a profile. We want that explicit already in the manifest.scm. However, my understanding is that the role of an importer is to create a manifest.scm or, more realistically, help a user get started creating it. There will probably usually need to be additional tweaking related to the intended application the computational environment supports. The CRAN importer, for example, cannot yet detect non-R dependencies. So, the profile author has to figure those out for themselves. It's still very useful despite not being perfect. 

>Last, considering all Guix the version fields, I am not convinced it is
>straightforward to guarantee some “nearby” or newer versions.  It can
>only be heuristics working with more or less accuracy; see “guix
>refresh” and all the updaters.

Sure, but as is shown with "guix import cran" as I previously mentioned, it doesn't have to be perfect to be really useful in many cases.

>All in all, I am not convinced Guix should try to implement a way to
>“specify the exact software version”.  Because it leads to false
>considerations that label versions are enough for reproducing
>computational environments, when it is far to be.

It definitely is not enough, but that is where its up to the profile author to flesh out many examples of what their software is supposed to do and verify those still work under Guix.

Having tools to benchmark against existing, but not long term reproducible, software environments would help in this import case because that is the goal with conda. Researchers should not expect to go from "good enough" for now to guaranteed reproducibility without also doing a lot of empirical testing. 

Researchers have to start somewhere and convenience often trumps other considerations at the beginning since most new projects fail. To get researchers to start from Guix, they need either an army of packagers willing to assist them with packaging or for there to be so much convenience in Guix to package new software such that it isn't much of a hassle for the researcher to do it. I hope for both, but feel like working towards the latter would bolster the chances of the former. You could imagine Xapian being used to suggest also additional package inputs just as "guix build -f" already suggests missing scheme modules.