IRC channel logs


back to list of logs

<zimoun>rekado, I agree on the general arguments. I disagree on concrete implementation. :-) Say “you can use Guix on Mac via Docker” means for my audience: the solution is Docker.
<zimoun>civodul, I agree from the Guix side. I disagree from the Guix for Science side. Say “Guix does not on Mac but only on Linux” means for my audience: Guix is only for cluster, so I do not care. Let drop that and focus on my work so I use Conda. Scientific reproduducibility is another level of priority.
<dstolfa>zimoun: i feel like "solution is docker with guix on top of it" is better than "solution is conda on macos"
<zimoun>this discussion is applying «The Right Thing» and not the «Worse is better». And as history demonstrates: more success with the «Worse is better» than «The Right Thing».
<zimoun>dstolfa: Who produces this Docker image? Size of this Docker image? etc. vs “bash” then light use. If Guix with Docker had been the solution for foreign distros, I will not be there. ;-)
<zimoun>efraim: yeah, I gave a look to Julia Documenter but it is too much for me.
<zimoun>Well, I will not work on porting Guix on Mac or Windows. Talk is cheap. :-) The point I *really* want to make: Guix for Science should not neglect these 2 platforms because it is today the large majority in Science. So what do we do for stretching them to what we consider «The Right Thing» (at least about reproducibility)?
<efraim>I was hoping to not have to work on the JavaScript part. The code comments suggest it wants a relative path which isn't as great
<civodul> <- how Spack gets everywhere
<efraim>The first criteria is Spack
<civodul>from the start it's had a level of political support that's crazy
<civodul>compared to our experience here, we can only be jealous
<zimoun>civodul, Spack works on Mac. ;-)
<civodul>for some value of "works"
<civodul>i don't this the project above is interested in macOS support though
<rekado>zimoun: the solution is Guix, using Docker as a “transport” is an implementation detail.
<efraim>Actually I might package an older version of Documenter.jl with fewer JavaScript dependencies first
<rekado>you wouldn’t say that the solution to package management is compressed archives and blur the distinctions between .deb and .rpm and Arch’s .tar.xz
<efraim>Does Spack work on Windows?
<civodul>efraim: everything works on Windows thanks to WSL :-)
<zimoun>rekado: hehe! :-)
<civodul>(at least that's my interpretation)
<efraim>Good point
<zimoun>everything works *on theory* on Windows thanks to WSL ;-)
<rekado>how well does Guix work on WSL?
<rekado>is this something that just works?
<efraim>So we should probably work on our docker story, smaller binaries and not missing /bin/sh or something
<rekado>I’d be happy to mention “also runs on Windows” in my future presentations
<efraim>My wife has WSL1, haven't tried installing Guix on it yet
<efraim>Just wait for the outage if we get an official Guix image in the Windows store
<civodul>rekado: there were reports of people who tried
<efraim>GSoC project anyone?
<civodul>but i'm not sure whether the conclusion is that it works
<efraim>Not sure if we need an /sbin/init shim
<efraim>And it might default to the Microsoft Linux kernel
<zimoun>I have in my bookmark <>
<rekado>would also be nice if “use Guix over Docker on a mac” would “just work” without excessive configuration.
<zimoun>but never tried… it is on my TODO since more than one year. :-(
<zimoun>from my understanding, the current issue with Guix on Docker is the image size. The initial one and then all the others each time you “pull“. Well, it was my impression about <>
<efraim>forgot about the ever increasing size
<efraim>I was going to ask about needing privileged mode for the extra build users
<zimoun>For sure, I will not work daily on Guix on Docker. Using Docker is fine once all is ready but not when as a researcher you are interactively experimenting: install that, try that, remove that, run, fix, re-run, etc.
<zimoun>To me, Guix on Docker is the same solution as ‘relocatable’.
<efraim>Is that something they do in docker? I like the 'insert this directory over there' aspect of it, so I guess you could experiment with it, then edit your docker file and spin that up again later