IRC channel logs
2022-04-14.log
back to list of logs
<zimoun_>rekado: could you comment about bioconductor-git-reference in #54787? Note that yesterday, the Bioconductor Git repo was unavailable. I do not know if it is related to their release for soon. <rekado>I’m reviewing and applying some R patches now <rekado>will try to comment on this later today <PaulePanter>Hi. Nice project. Some nit pick about the Web site, the logo looks blurry on a HiDPI (4K) screen. ;-) <PaulePanter>Or how do others manage different versions on their installations? <zimoun_>PaulePanter: I do not know where does the load-profile comes from. Otherwise, ’eval $(guix package --search-paths=prefix)’. <zimoun_>env -i $(which bash) --login --noprofile --norc <PaulePanter>Does that also work with several installed versions in parallel? <rekado>PaulePanter: I maintain guix.mdc-berlin.de <PaulePanter>We currently (without guix) manage our own package infrastructure with several versions of scientific packages installed in parallel, and have a wrapper `prun` settings up the environment accordingly. If anyone is interested: https://paste.debian.net/1237947/ <zimoun_>rekado: thanks for your answers about bioconductor and Git. :-) <zimoun_>PaulePanter: basically, you can have as many profile as you want. So yes, it works with multiple parallel installed versions. <zimoun_>Currently, mainstream Guix provides only one version of R. For instance, compare “guix shell gcc-toolchain@7 -- gcc --version” and “guix shell gcc-toolchain@10 -- gcc --version” which basically does the dance of ’prun’ <rekado>zimoun_: I cannot reproduce your reported failure in building the “orange” package. Is it broken at runtime? <rekado>weird. I cannot reproduce this on my laptop. <zimoun_>I do not know. It fails on my desktop machine. And Cuirass says it comes from the recent PyYAML@6 merge. But the dependency is not straightforward. <zimoun_>Well, I have not investigated more. Just tried an update here and there but still. <rekado>I get a different derivation on my laptop than the failing one on ci.guix.gnu.org <rekado>mine is /gnu/store/x9aj1mdh213ivmbsgba78p6diz9q4x19-python-orange-canvas-core-0.1.24.drv <rekado>but even /gnu/store/aj4xvw8shwjq9qpyfbswb71jk7axf26h-python-orange-canvas-core-0.1.24.drv (the one failing on ci.guix.gnu.org) builds fine here. <PaulePanter>zimoun_: Does that also work with shebang line in scripts? <rekado>zimoun_: I just built it manually on ci.guix.gnu.org and it worked fine <zimoun_>rekado: it also fails on my desktop. <zimoun_>by “build it manually”, do you mean restart build? <rekado>no, “guix build /gnu/store/….drv” on the command line. <old>Hi! If I've installed gwl globally with `guix install glw` what would be the correct way of setting up `GUIX_EXTENSIONS_PATH` for `guix workflow`? <old>My idea was to use `guix build glw` to find the store entry, create a root in `/var/guix/gcroots` and symlink to that root. Is this the correct way of doing it? <zimoun_>old, what do you mean by “globally”? <old>Or I could use `guix shell` and extend guix using `$GUIX_ENVIRONMENT`. I'm not sure which approach is the best. <old>`guix install glw` so really in the current profile <old>I would prefer a solution with `guix shell` so anyone can clone the project and launch the workflow without any installation process. <old>oh well `guix shell --pure guix gwl` seems to be enough <rekado>adding guix to the pure shell is probably not a good idea <rekado>after installing gwl export GUIX_EXTENSIONS_PATH=$HOME/.guix-profile/share/guix/extensions/ <old>okay. What if I want a `wf-env` script in my project? <old>So that someone can do `./wf-env run-workflows` <rekado>note that there are fixed bugs in the latest version of GWL, but there hasn’t been a new release yet. <old>Because ideally, I would also use `guix time-machine` in the script <old>Okay. I'm also trying a few examples in the manual and getting `error: 1.31 Wrong type argument in position 1 (expecting struct): #f` during the preparation <old>is this a known issue? <old>Okay cool. I'm not in an hurry so I will wait for the new release. Do you have a date in mind? <rekado>I think I can do this some time next week. <rekado>I actually wanted to add a few more features to improve performance, but I haven’t been able to make enough time for that. <civodul>rekado: it's annoying that one has to set GUIX_EXTENSIONS_PATH manually <civodul>i have the same problem with guix-modules <zimoun_>Somehow, I proposed a default location as ~/.config/guix/ <zimoun_>Well, feel free to comment the mentioned thread, if it is worth. ;-)