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