IRC channel logs
2025-06-02.log
back to list of logs
<Kabouik>Thanks rekado for the information. So the way I understand it, going back to arbitrary older versions of R without a channels.scm containing hashes, and time-machine and shell combined with a manifest, is going to be tricky in some cases. If the users can get the good habit of running `guix describe` and listing their packages in a manifest, however, it'll be easy to redeploy their future work with the same versions of R and packages. <Kabouik>So maybe next time I talk to the admin and potential users, I can be more cautious regarding the "easy to use old versions of R" speech I had, and just say "easy to redeploy the work you'll do with the same packages and R versions if you ran guix describe beforehand". <Kabouik>I am finding that even time-machine is not 100% reliable. Last week my test command `guix time-machine --commit=af02327856 -- shell --with-git-url=guix=https://codeberg.org/guix/guix rstudio r-minimal r-ggplot2` was failing presumably because the server was having issues, but now it fails to build guix-cran.drv`. Maybe I should retry with the `-q` flag to time-machine, I guess it might be trying to use my channels.scm even though I gave it only <Kabouik>the commit and url of the guix channel. <Kabouik>Re: "if the organization has the capacity for it, a research engineer position could be used" > Definitely not, sadly. We don't have a proper IT team here (some units do in other places, but they're focused on the IT angle and modelling, which is not our case). The only people hired for IT here are those dealing with the user PCs, every day issues, and are usually hired at in Technician positions. And they're alone, not teams. The institutions <Kabouik>promotes reproducible science of course, but really does not commit to hiring people for the task or for optimizing our workflows with computing. <Kabouik>I have received several answers to my mail sent to guix-science, I imagine some of the people who replied are here in this channel. I just didn't take the time to process all the information today. <Kabouik>No, adding `-q` to time-machine didn't make the command work (but the error is no longer related to guix-cran so I assume it's indeed going in the right direction): https://0x0.st/8YjD.txt <flypaper-ultimat>how far are you going back? there was a time when 'guix shell' was only availably as 'guix environment --ad-hoc' <flypaper-ultimat>yeah, and 'guix time-machine --commit=...' does not 'reset' your 'guix describe' to just be the guix channel, it keeps everything form your 'guix describe', but sets specifically the guix channel to that commit <flypaper-ultimat>correction, it would use your $HOME/.config/guix/channels.scm, but with guix channels commit to the value of --commit <flypaper-ultimat>Kabouik: Yeah, 'guix shell' did not yet exist at that commit, you'll want to use 'guix environment --ad-hoc' <flypaper-ultimat>(or in the case of time-machine "guix time-machine <time-machine-stuff> -- environment --ad-hoc <your-previous-guix-shell-stuff>") <Kabouik>Right, I had forgotten about the environment -> shell change, good catch. Thanks. <Kabouik>My commands also tries to install rstudio, which is from guix-science. Can I just add several channels in the --url and --commit flags, or should I just run the first environment --ad-hoc, then run another one inside it if I need to pull from another channel? <Kabouik>To be clear, there is no `guix describe` involved here. I think I know the `guix describe` and `guix time-machine -c channels.scm -- shell -- etc.` workflow, but I was trying to see here if it was possible to pull software from old versions in a one liner command, for those situations where people would not already have prepared the grounds for reproducible environment. <flypaper-ultimat>you would need to make a channels file though, containing both guix and guix-science <Kabouik>So as far as I understand, without the -q flag, it will use my ~/.config/guix/channels.scm and just specify a commit to the Guix channel (the one defined in --with-git-url=guix=<url>), but not other channels, which will likely lead to conflicts <flypaper-ultimat>guix-science (and -cran, and -bioc) are kinda 'in lockstep' with the guix channel <Kabouik>Re: "do you want your rstudio to also be 'from the past?" > In that case, not particularly, a newer version of rstudio would do just fine because it would use the old R version in the shell. This is all theoretical, I use Emacs ESS, but 99% of users use Rstudio and it's a real case scenario for them <flypaper-ultimat>so if you 'guix time-machine --commit=deadbeef' without -q, and your $HOME/.config/guix/channels.scm contains a guix-science that uses a symbol (i.e. package, funciton) that was introduced in the 'guix' channel after deadbeef, it will error. <Kabouik>Right, so if I want a shell with `rstudio r@oldversion r-somepackage` (coming from different channels) and try to target a commit with --commit=deadbeef (i.e., not with a prior guix-describe and manifest from a state that is known to have been working at some point), then the limiting factor is the most recent package because it was introduced after the others I'm pulling. If I understand well, this one-liner command with --commit will work best <Kabouik>if I'm pulling from a single channel, and in that case it's best to use `time-machine -q` to avoid any issues. <Kabouik>I guess a side question would be: is it possible create a shell with some old R version and then use the software inside that shell from software not in that shell? Example: Alice has Rstudio installed and up to date, and R up to date too. She needs R 4.0.0.0 and finds that --commit=deadbeef on the Guix channel will provide her just that. `guix time-machine -q --commit=deadbeef --with-git-url=guix=<codebergurl> -- shell (or environment --ad-hoc) <Kabouik>r-minimal` will provide just that. Can she run her main profile Rstudio inside the guix shell where R 4.0.0.0 is installed? <flypaper-ultimat>you could 'guix time-machine -q --commit=deadbeef -- r-minimal r-ggplot2 -- R -e '.libPaths()' and set your external R session .libPaths to that <flypaper-ultimat>(only would be a problem if the packages you specify put things on your $PATH and use them) <flypaper-ultimat>with -q --commit= you can only use the guix channel though, i really recommend making a channels.scm file per project. <Kabouik>Re: "i really recommend making a channels.scm file per project" > That is what I started doing recently but so far I'm the only Guix user in the group, others would maybe use it if it was installed on the cluster. From there I could recommend that they do it, but if they need to continue work that they've started before with older versions of R, they may be interested in installing abritrary old R versions. <Kabouik>I see that installing arbitrary versions from the past is by no means trivial though, as opposed to restoring from a guix describe and manifest. <Kabouik>R -e '.libPaths()' > clever. I'll have to try that. Not exactly straightforward to teach to users who just want to run Rstudio and are used to having it offer multiple R versions from the detected local installations in Windows though. <Kabouik>I'm not sure. I assumed it would but I don't know. In Windows local installations, I know users who launch Rstudio are offered multiple R versions depending on what is installed locally on their machine. I guess it's the same in Linux although I'm not sure how multiple concurrent R versions can co-exist (libraries can be compjiled in a $HOME subfolder containing the R version so can be version-specific, but I don't think R itself is installed in <Kabouik>In any case, I might be trying too hard to demonstrate all the strengths of Guix. I think Rstudio users would be happy to just use the latest server-installed R version in Rstudio, and only use R console for older versions. If they learn guix-describe and manifests, then they can have both for their future work, but not for the past one (not easily at least). Targeting a specific version in the past, however, is going to be hard. Maybe module <flypaper-ultimat>yeah, 1. getting a non-guix-watched project exactly as you had it is gonna be impossible. 2. if you wanna go to the past, i suggest looking at searching https://data.guix.gnu.org/ for the package with the 'hardest dependency' and finding one that matched the most, and going using that commit <Kabouik>Re: "(ess does make this so much easier)": Just curious, how would you do that with ESS? I never needed it but am intersted. `(setq-default inferior-R-program-name "/path/to/guix-shell/with/old/R")`? <flypaper-ultimat>M-x shell; "guix time-machine <stuff> -- shell r-minimal r-gglot2 <stuff> -- R"; M-x ess-remote <flypaper-ultimat>yeah alternatively you can make a shell script with 'guix time-machine <stuff> -- shell r-minimal r-gglot2 <stuff> -- R "$@"' and set that to your inferior-R-program-name <flypaper-ultimat>(to the past cont) because usually when a user says 'i want to use package FOO at version x.y.z' they mean, "I want an environment that is most compatible with FOO@x.y.z" <flypaper-ultimat>and for guix, that was when the guix channel contained the package at x.y.z. <flypaper-ultimat>Kabouik: so if your researcher has Rstudio in their, they could do "guix time-machine <stuff> -- shell --pure r-minimal r-ggplot2 <stuff> -- $(which rstudio)" <Kabouik>Oh, so $(which) will go pick software outside the shell, nice. That's what I was wondering. You added --pure here, do they really need to hide their environment from the shell? <Kabouik>I'm sorry there are probably questions I could answer myself (and I am trying), but my test `time-machine` command is still building since forever, so I can't test anything until it's done <flypaper-ultimat>in case they had an R environment managed by guix with e.g. "guix install r-minimal; guix install r-ggplot2" <flypaper-ultimat>(which i wouldn't recommend, but it useful e.g. with ess for browsing & linting code) <Kabouik>Oh, that's actually what I use on my machine (single user) but you're not recommending it. :< <flypaper-ultimat>its also what i use, but mostly for browsing. (its actually in one of my profiles). On a per project basis i have a manifest.scm and a channels.scm (the list of packages for R) <Kabouik>What I did recently was make my analyses with my environment and my packages installed from Guix (without shell or manifest), then when finished, run a guix describe and create my manifest from the packages I actually ended up using. This way I didn't have to use shell for months during the analyses (and possibly pin old versions while newer ones released in the mean time would still have worked until the work was published) <Kabouik>But maybe there are issues with this approach <flypaper-ultimat>if you didnt use 'guix pull && guix package -u' and didnt work with guix on other projects i guess its okay. i.o.w if you only used guix for that project. guix shell --pure also help you catch when you use system libraries on a foreign distro (or thing in your other 'active' guix profiles, also relevant on guixSD) <Kabouik>Awesome, thank you very much. I'll have to play with that a bit to try explaining it to potential users, or even add some flags and a --help for them to use easily without editing commits in it <Kabouik>I'm not sure, I have started using the guix-cran channel to avoid such issues to be honest <Kabouik>I know it's ideal when packages are in Guix but in practice this was often an issue that could not be solved immediately when I needed the package, I imagine it'd be the same for others.