<zimoun>Hum, I am missing how propagated inputs is avoidable for R. But it is possible, for sure it will be better.
<zimoun>However, for the general case, the only way to avoid some conflicts of propagated inputs when using “guix upgrade” would be to add a version resolver… which would defeat the main message about reproducible computational environment.
<rekado>I don’t think it’s possible to avoid with R.
<rekado>I just read the code in src/library/base/R/library.R
<rekado>there’s a clear assumption that there’s a global mapping from plain names to objects; when a namespace has been attached it will be loaded
<rekado>when a namespace has been loaded it won’t be loaded again
<rekado>we would have to patch R significantly to work around this, and I’d rather not attempt it
<rekado>R packages would have to have their own namespace mapping (falling back to a parent environment); while the mechanism for nested environments exists it is not used for namespace discovery
<rekado>the machinery is also distributed between different procedures, each of which would have to be aware of the modified discovery mechanism
<zimoun>well, heavily patching R would lead to more work for maintenance
<rekado>taking a step back: could we just create a really long load path with absolute /gnu/store directory names instead of propagating things?