[Rd] Proposal to limit Internet access during package load
Blätte, Andreas
@ndre@@@b|@ette @end|ng |rom un|-due@de
Wed Sep 28 10:09:26 CEST 2022
Dear Tomas, thank you so much for the explanation. Very helpful for myself, and relevant for the wider context of packages using rwinlib! Andreas
Am 27.09.22, 20:18 schrieb "Tomas Kalibera" <tomas.kalibera using gmail.com>:
On 9/27/22 18:42, Blätte, Andreas wrote:
> Dear all,
>
> my apologies for a dull question. I think I do understand that unnoticed Internet access requires scrutiny and a more explicit approach.
>
> But I am not sure how this would impact on the practice on many Windows machines to download static libraries from one of the rwinlib repositories? See https://github.com/rwinlib, an approach taken by quite a few packages (src/Makevars.win triggers tools/winlibs.R for downloading a static library).
>
> I am asking because a package I maintain (RcppCWB) uses the approach, and am not sure whether and how the discussion has addressed this scenario. It may not be covered by Iñakis initial three scenario?
Dear Andreas,
please let me clarify for others that your package only downloads
pre-compiled static libraries for R 4.1 and earlier on Windows, what is
already now the "old release" and will not be checked against by CRAN
once R 4.3 is released. For R 4.2 ("release") and R-devel, your package
includes the source code of the library and links it, which is in
compliance with the CRAN policy. So if any new possible restriction in
downloading along the lines Inaki raised was set, it probably won't
affect you.
Downloading pre-compiled static libraries is only possible as very last
resort and only with agreement of the CRAN team - see the CRAN policy
for details (https://cran.r-project.org/web/packages/policies.html, look
for "external"). In other words, unless those special conditions are
met, it is already banned now.
More explanation for why it is a bad thing can be found in
https://cran.r-project.org/bin/windows/base/howto-R-4.2.html:
"For transparency, source packages should contain source (not executable
code). Using pre-compiled libraries may lead to that after few years the
information on how they were built gets lost or significantly outdated
and no longer working. Using older binary code may provide insufficient
performance (newer compilers tend to optimize better). Also, the CRAN
(and Bioconductor) repositories are used as a unique test suite not only
for R itself but also the toolchain, and by re-using pre-compiled
libraries, some parts will not be tested. Compiler bugs are found and
when fixed, the code needs to be re-compiled. Finally, object files (and
hence static libraries, particularly when using C++) on Windows tend to
become incompatible when even the same toolchain is upgraded. Going from
MSVCRT to UCRT is an extreme case when all such code becomes
incompatible, and adding support to 64-bit ARM would be another extreme
case, but smaller updates of different parts of the toolchain or even
some libraries in it lead to incompatibilities. The issues mentioned
here are based on experience with the transition to UCRT and Rtools42;
all of these things have happened and dealing with the downloads and
re-use of static libraries was one of the biggest challenges."
With respect to any possible restriction on downloading in principle,
this is no different from downloading external source code (both is
needed when the native code of packages is being built, so during "R CMD
INSTALL"), and that has already been mentioned in this thread. So it
doesn't have to be discussed specially I think.
Best
Tomas
>
> Kind regards, Andreas
>
>
>
>
>
> Am 27.09.22, 10:15 schrieb "R-devel im Auftrag von Iñaki Ucar" <r-devel-bounces using r-project.org im Auftrag von iucar using fedoraproject.org>:
>
> El mar., 27 sept. 2022 4:22, Dirk Eddelbuettel <edd using debian.org> escribió:
>
> >
> > Regarding 'system' libraries: Packages like stringi and nloptr download the
> > source of, respectively, libicu or libnlopt and build a library _if_ the
> > library is not found locally. If we outlaw this, more users may hit a
> > brick
> > wall because they cannot install system libraries (for lack of
> > permissions),
> > or don't know how to, or ... These facilities were not added to run afoul
> > of
> > best practices -- they were added to help actual users. Something to keep
> > in
> > mind.
>
>
> Yes, but then IMO Internet access should be explicitly enabled by the user
> with a flag. By default, it should be disabled and packages on CRAN should
> install as is.
>
> Iñaki
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list