[Rd] Respecting custom repositories files in interactive/batch R sessions

[Gabriel Becker]

Hi Kurt,

Thanks.

On Fri, Sep 16, 2022 at 12:57 AM Kurt Hornik <Kurt.Hornik using 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 using 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 using debian.org
> >>
>
> >       [[alternative HTML version deleted]]
>
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]