IRC channel logs
2021-09-10.log
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 conda-install.sh” 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>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>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 <civodul>efraim: everything works on Windows thanks to WSL :-) <zimoun>everything works *on theory* on Windows thanks to 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 <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 <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. :-( <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