<zimoun>rekado_: piouf! I have almost clean all the mean I did with the wip-r branch and aside a couples of packages, all the updates build now. I will push it tomorrow.
<zimoun>Well, I have learnt a lot about the workflow with this. :-)
<PurpleSym>rekado_: I’ve been running into this “we just install unreleased -dev packages from GitHub that are totally incompatible with stable versions” paradigm as well. Is it possible to point the CRAN importer to a GitHub repository right now?
<rekado_>it’s in the manual, but “guix import cran --help” is awfully terse
<PurpleSym>Oh, you’re right. I must have overlooked that.
<PurpleSym>I also thought about overriding install.packages, but for now I just disabled it via RStudio’s `allow-package-installation=0`
<rekado_>I’m not an actual R hacker, so I don’t know if it’s possible to override the implementation of install.packages in the base library without patching it.
<rekado_>I’d like to rename the existing implementation and fall back to it in case installation via Guix has been disabled
<rekado_>using the same name would unlock installation of packages through Guix via RStudio and all other tools that happen to use install.packages.
<PurpleSym>(The same is true for `pip install` as well)
<PurpleSym>As for implementation, RStudio registers a hook using .rs.registerReplaceHook(). The implementation is in src/cpp/r/R/Tools.R (registerHook). Does not look RStudio specific right now, but I’m also not a R hacker.
<rekado_>I’d like to make this change in R itself. I find RStudio a little confusing, because some of the features it provides are only possible because it implements its own shell around libR.so, so a bunch of features are not backed by the R language itself but by custom extensions in their own shell.
<zimoun>rekado_: There is are still 9 packages that do not build. I am going to push to my branch on GitHub. I have rewritten the history and the each commit builds, aside corner cases.
<zimoun>civodul, PurpleSym: about yesterday “workflow“ conversation, well, on one hand the answer seems .guix.scm or GWL, on the other hand, I do not think the old bad habbits will change. Recently, discussing about LaTeX and co, <https://infomath.pages.math.cnrs.fr/talk/2020-2021/latex/> (French), it is clear that a lot of bad practises are still used… and it si *so* slow to change. Anyway.
<civodul>slow to change should not be an excuse for doing nothing ;-)
<zimoun>civodul, rekado_: about R, colleagues and popularity, I am seeing more or less the same thing as rekado_ in my lab. It is easier to do quick&dirt and it works than fix the hard way. Especially when a lot of researchers do not really undertand what the tool is doing (not to say: they do not know what they are doing). Again, bad habbits are so hard and slow to change… out of scope of Guix, maybe.
<rekado_>but whenever PYTHONPATH is discussed my brain leaves me
<rekado_>I’ve been an active participant in and instigator of PYTHONPATH discussions in the past, but nothing ever came of them
<rekado_>the last I read was Hartmut’s analysis of our options and their downsides
<rekado_>I do think we need to stop setting PYTHONPATH, but I lack the patience to re-read all past discussions to see a path forward
<rekado_>I’ll gladly leave this to people who aren’t yet fed up with Python :)
<zimoun>I agree about habbits. But similarly I am still seeing more than often \def instead of \newcommand with LaTeX. You can have the best luatex engine, if user use old bad habbits and shoot them in the foot, what is doable?
<rekado_>but it’s one of those things that we shouldn’t break needlessly
<rekado_>there can be fundamental obstacles, but anything beyond that should not be due to sub-optimal design on our side
<rekado_>it is fine, for example, to install gcc-toolchain and build your own software without packaging it for Guix
<rekado_>that’s often far from the best way to do things, but we don’t make it impossible
<rekado_>there are quite a few things wrong with our use of PYTHONPATH, and they lead to actual problems; so while we’re motivated to look for alternatives it’s good to see if they collide with well-established habits
<civodul>it's problematic that PYTHONPATH discussions haven't led to a concrete set of actions we could take
<rekado_>there’s a danger in having a person take the lead just as much as there is in apathy
<civodul>i remember being overwhelmed by these discussions
<zimoun>rekado_: I agree with your points, metaphorically my point is The Right Thing is learn music (instrument theory, music thoery, etc.) and today people (scientifist) just grad an out-of-tune guitar, watch a video on well-known platform and practise enough just to play alone around the camp fire. Then they say: hey! I know music and I am not interested by trying your crazy instrument in this band even if I can do better with both.
<zimoun>That’s your example with your or my colleagues, for instance. :-)
<rekado_>zimoun: I’m going to lean far out the window now, but… I think it’s absolutely fine for people *not* to know music theory and have fun playing an instrument, even when they could do better and perhaps enjoy more.
<rekado_>my lab colleagues certainly know their stuff
<rekado_>but they use software as a means to an end
<rekado_>if at some point in their journey they realise that they probably should have been a little more principled at the beginning — that’s fine
<rekado_>often enough, though, it’s totally fine not to do the right thing from the start
<rekado_>sometimes quick exploration is a goal in itself
<rekado_>there are a few systems out there that claim to describe the final environment you ended up with, so that you can report on your setup for publications
<civodul>one takeaway here is that guix should support quick exploration better
<rekado_>this shows that people often start their explorations haphazardly
<zimoun>I agree with you about scientific software unavailable in Guix, and I remember asking exposing <license> for this very same reason and your arguments here were mine at the time, mine were yours. ;-)
<zimoun>my question is simply: does it make sense to mix “import” (impure) with “build” (pure)?
<zimoun>use the state of outside, not stateless, not: what you get is what I get (WYGIWIG :-))
<zimoun>Well, I will think about it. ;-) The streamlining and reproducibilit is a good question, IMHO.
<zimoun>rekado_: I have 356 packages that build. Missing only 2.
<rekado_>zimoun: excellent! Do you need help with the missing two?
<zimoun>rekado_: yes maybe. Thank you for let me the time to learn. The journey was very fruitful. :-) I have tried to unknot the mess I created, well, it should be ok, even if maybe some propagated inputs still remain and they are not necessary. And I will try to summarize what I have learnt and then open a discussion with the Cuirass’s guy to see how to should be possible to avoid rebuilding all locally and avoid blocking with
<rekado_>but maybe they are just too busy fact checking realDonaldTrump, so their support staff can’t fix this for us.
<zimoun>rekado_: I am rebuilding everything (detect missing HDF5 annoying empty dir) and I need to fix a couple of commit messages. Well, I have rewritten the history, so then nothing should be broken. The draft result is here https://github.com/zimoun/guix
<zimoun>civodul: bug#42371 is annoying about massive rebuild «guix build: error: all build users are currently in use;…». So I end up with a shell for-loop :-(. And I am not sure to have the right tools to debug that.
<civodul>zimoun: i don't experience it so you'll have to fix yourself muahaha
<zimoun>it is because you are not building enough ;-)
<zimoun>somehow, the scheduling strategy of the dameon is not clear for me
<rekado_>let me know when the commit messages are fine; I’ll then fetch.
<zimoun>ok, the propagated-inputs are not all clean yet
<zimoun>rekado_: one more r-affycompatible-1.50.0 :-)
***rekado_ is now known as rekado
<zimoun>rekado: 2 packages are BROKEN as the commit message says. The rest builds. All the history, package per package, should build; even if I have not double-checked that. In the last state, all the packages from Bioconductor build; double-checked. All the propagated-inputs are not set at the minimum. I could finish to unknot the mess I did with that but before, I would prefer that you give a look and let Cuirass builds and check.