<flypaper-ultimat>I wonder why you would want this though, because you'd lose all the advantages guix right? I'm not too familiar with spack, but do they do e.g. things to remove randomness in build processes?
<rekado>I think you wouldn’t just lose the advantages of Guix but also the advantages of Spack
<rekado>the motivation seems to be the desire to use packages from wherever they exist
<rekado>oh, Guix doesn’t have a tensorflow 2 package? Spack does! But I don’t want to commit to using Spack for all my Guix things. Wouldn’t it be great if Guix could use the Tensorflow 2 from Spack then…?
<rekado>that said, I do sometimes recommend the use of Guix even if it doesn’t reach all the way to the tip of the leaf package in question.
<rekado>e.g. to use Guix for the foundation: Python, GCC toolchain, bunch of libraries, some Python packages, etc. And then build software on top of that in a “guix shell -C” environment.
<rekado>that’s better than throwing out all of Guix just because some Python module isn’t available yet.
<flypaper-ultimat>w.r.t building in a `guix shell -C`; ah cool, havent thought about going about it that way.
<zimoun>yeah, I also recommand something similar. To be precise, create an environment for building on the top of it: “guix time-machine -qC pins.scm -- shell -C -m deps.scm”, and then write down all the steps (à la labnotebook :-))
<rekado>many people at the MDC do this without knowing that this is what they do. We provide an rstudio-server launcher that comes with most libraries and tools that they might need. Inside this environment they can use install.packages.