Gabriel Becker
2022-Sep-16 16:04 UTC
[Rd] Respecting custom repositories files in interactive/batch R sessions
Hi Kurt, Thanks. On Fri, Sep 16, 2022 at 12:57 AM Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote:> >>>>> Gabriel Becker writes: > > Friends, > > I always keep forgetting how these things currently/precisely work, but > I guess the principle is that utils:::.onLoad() does > > options(repos = c(CRAN = "@CRAN@")) > > unless the repos option was already set (in the user or site profiles). > As the latter are not used when checking, the check code in tools takes > advantage of the repositories file mechanism, see ? setRepositories: > > The default list of known repositories is stored in the file > ?R_HOME/etc/repositories?. That file can be edited for a site, or > a user can have a personal copy in the file pointed to by the > environment variable ?R_REPOSITORIES?, or if this is unset or does > not exist, in ?HOME/.R/repositories?, which will take precedence. > > which also points to Startup etc). >Yes this is exactly what happens.> > I guess one could teach utils:::.onLoad() to use the user/site > repositories setting instead of the hard-wired CRAN = @CRAN@? Afaict, > that would make no difference if the repositories file was not > configured, and provide the configured setting in case repos was not set > in the user/site profile ... >Precisely, that is my proposal. I have a patch which does this and passes make check-devel for me (there is some slight technical gotchas because tools::get_repositories calls utils::read.delim which isn't available yet during utils::onLoad execution), but I have a workaround for that that works. If the consensus is that this is a good idea I'm more than happy to submit the patch, along with an update to the admin manual reflecting the change (either together or as separate issues). Best, ~G> > Best > -k > > > > Hi Dirk, > > So there's a couple of things going on. First off you're correct that > that > > works generally. There are a couple of reasons that made it not. The > first > > is a bug/design error in Rstudio which is causing the R_PROFILE to not be > > adhered to when you build there. I will be filing a bug regarding that > with > > them, as I know that is irrelevant to this list. There was some > indication > > that even raw R CMD check running via an R studio server installation was > > missing the profile, but that ended up being spurious upon deeper > testing. > > > That said, I do think that there is a case to be made for the ability to > > modify what repositories R knows about at a more fundamental level than > > setting options in a site profile, and that is, ostensibly, what the > > repositories file machinery does. I understand it was intended initially > > and is currently only (?) used for the windows repository gui menu and > > related setRepositories function, but I still think there is some value > in > > extending it in the ways I described. > > > One major difference is that in this case, even when run with --vanilla, > > administrators would still be in control of which repositories users hit > > (by default only, of course, but there is still value in that). > > > Best, > > ~G > > > On Thu, Sep 15, 2022 at 11:31 AM Dirk Eddelbuettel <edd at debian.org> > wrote: > > >> > >> I may be missing something here but aren't you overcomplicating things? > >> One > >> can avoid the repetitive dialog by setting options(repos) > accordingly, > >> and I have long done so. The Debian (and hence Ubuntu and other > >> derivatives) > >> package does so via the Rprofile.site I ship. See e.g. here > >> > >> https://sources.debian.org/src/r-base/4.2.1-2/debian/Rprofile.site/ > >> > >> I have used the same mechanism to point to intra-company repositories, > >> easily > >> a decade or so ago. I had no problems with R CMD check of in-house > packages > >> using this. > >> > >> Dirk > >> > >> -- > >> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org > >> > > > [[alternative HTML version deleted]] > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Kurt Hornik
2022-Sep-16 16:46 UTC
[Rd] Respecting custom repositories files in interactive/batch R sessions
>>>>> Gabriel Becker writes:Thanks. Perhaps submit your patch via R-bugs? (I would have hoped we can simply use tools:::.get_repositories() right away ...) Best -k> Hi Kurt, > Thanks.> On Fri, Sep 16, 2022 at 12:57 AM Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote:>> >>>>> Gabriel Becker writes: >> >> Friends, >> >> I always keep forgetting how these things currently/precisely work, but >> I guess the principle is that utils:::.onLoad() does >> >> options(repos = c(CRAN = "@CRAN@")) >> >> unless the repos option was already set (in the user or site profiles). >> As the latter are not used when checking, the check code in tools takes >> advantage of the repositories file mechanism, see ? setRepositories: >> >> The default list of known repositories is stored in the file >> ?R_HOME/etc/repositories?. That file can be edited for a site, or >> a user can have a personal copy in the file pointed to by the >> environment variable ?R_REPOSITORIES?, or if this is unset or does >> not exist, in ?HOME/.R/repositories?, which will take precedence. >> >> which also points to Startup etc). >>> Yes this is exactly what happens.>> >> I guess one could teach utils:::.onLoad() to use the user/site >> repositories setting instead of the hard-wired CRAN = @CRAN@? Afaict, >> that would make no difference if the repositories file was not >> configured, and provide the configured setting in case repos was not set >> in the user/site profile ... >>> Precisely, that is my proposal. I have a patch which does this and passes > make check-devel for me (there is some slight technical gotchas because > tools::get_repositories calls utils::read.delim which isn't available yet > during utils::onLoad execution), but I have a workaround for that that > works.> If the consensus is that this is a good idea I'm more than happy to submit > the patch, along with an update to the admin manual reflecting the change > (either together or as separate issues).> Best, > ~G>> >> Best >> -k >> >> >> > Hi Dirk, >> > So there's a couple of things going on. First off you're correct that >> that >> > works generally. There are a couple of reasons that made it not. The >> first >> > is a bug/design error in Rstudio which is causing the R_PROFILE to not be >> > adhered to when you build there. I will be filing a bug regarding that >> with >> > them, as I know that is irrelevant to this list. There was some >> indication >> > that even raw R CMD check running via an R studio server installation was >> > missing the profile, but that ended up being spurious upon deeper >> testing. >> >> > That said, I do think that there is a case to be made for the ability to >> > modify what repositories R knows about at a more fundamental level than >> > setting options in a site profile, and that is, ostensibly, what the >> > repositories file machinery does. I understand it was intended initially >> > and is currently only (?) used for the windows repository gui menu and >> > related setRepositories function, but I still think there is some value >> in >> > extending it in the ways I described. >> >> > One major difference is that in this case, even when run with --vanilla, >> > administrators would still be in control of which repositories users hit >> > (by default only, of course, but there is still value in that). >> >> > Best, >> > ~G >> >> > On Thu, Sep 15, 2022 at 11:31 AM Dirk Eddelbuettel <edd at debian.org> >> wrote: >> >> >> >> >> I may be missing something here but aren't you overcomplicating things? >> >> One >> >> can avoid the repetitive dialog by setting options(repos) >> accordingly, >> >> and I have long done so. The Debian (and hence Ubuntu and other >> >> derivatives) >> >> package does so via the Rprofile.site I ship. See e.g. here >> >> >> >> https://sources.debian.org/src/r-base/4.2.1-2/debian/Rprofile.site/ >> >> >> >> I have used the same mechanism to point to intra-company repositories, >> >> easily >> >> a decade or so ago. I had no problems with R CMD check of in-house >> packages >> >> using this. >> >> >> >> Dirk >> >> >> >> -- >> >> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org >> >> >> >> > [[alternative HTML version deleted]] >> >> > ______________________________________________ >> > R-devel at r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel >>> [[alternative HTML version deleted]]> ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel