Re: Google Summer of Code 2023 Inquiry

[Kyle]

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