[R-pkg-devel] Clarifying CRAN's external libraries policy

Nic Crane th|@|@n|c @end|ng |rom gm@||@com
Mon Jan 29 23:50:37 CET 2024


Thanks Simon.

As far as I can tell, I did not receive any reply to that email; would you
mind re-sending it?

Nic


On Mon, 29 Jan 2024, 19:31 Simon Urbanek, <simon.urbanek using r-project.org>
wrote:

> Nic,
>
> as far as I can see that thread was clearly concluded that it is not a
> special case that would require external binary downloads.
>
> Cheers,
> Simon
>
>
> > On Jan 30, 2024, at 11:11 AM, Nic Crane <thisisnic using gmail.com> wrote:
> >
> > Hi Simon,
> >
> > The email that Neal is referring to was sent by me (this email
> > address) to CRAN using r-project.org on Mon, 23 Oct 2023.
> >
> > Thanks,
> >
> > Nic
> >
> >
> > On Mon, 29 Jan 2024 at 18:51, Simon Urbanek <simon.urbanek using r-project.org>
> wrote:
> >>
> >> Neal,
> >>
> >> generally, binaries are not allowed since CRAN cannot check the
> provenance so it's not worth the risk, and it's close to impossible to
> maintain them over time across different systems, toolchains and
> architectures as they evolve. Historically, some packages allowed to
> provide binaries (e.g., back when the Windows toolchain was not as complete
> and there was only Win32 target it was more common to supply a Windows
> binary) and CRAN was more lenient, but it should be avoided nowadays as it
> was simply too fragile.
> >>
> >> As Andrew pointed out in special circumstances you can use external
> hash-checked *source* tar balls, but generally you should provide sources
> in the package.
> >>
> >> I do not see any e-mail from you to CRAN using r-project.org about this, so
> please make sure you are using the correct e-mail if you intend to plead
> your case.
> >>
> >> Cheers,
> >> Simon
> >>
> >>
> >>
> >>> On Jan 30, 2024, at 3:11 AM, Neal Richardson <
> neal.p.richardson using gmail.com> wrote:
> >>>
> >>> Hi,
> >>> CRAN's policy on using external C/C++/Fortran/other libraries says:
> >>>
> >>> "Where a package wishes to make use of a library not written solely
> for the
> >>> package, the package installation should first look to see if it is
> already
> >>> installed and if so is of a suitable version. In case not, it is
> desirable
> >>> to include the library sources in the package and compile them as part
> of
> >>> package installation. If the sources are too large, it is acceptable to
> >>> download them as part of installation, but do ensure that the download
> is
> >>> of a fixed version rather than the latest. Only as a last resort and
> with
> >>> the agreement of the CRAN team should a package download pre-compiled
> >>> software."
> >>>
> >>> Apologies if this is documented somewhere I've missed, but how does
> one get
> >>> CRAN's agreement to download pre-compiled software? A project I work
> with
> >>> has been seeking permission since October, but emails to both
> >>> CRAN using R-project.org and CRAN-submissions using R-project.org about this have
> not
> >>> been acknowledged.
> >>>
> >>> I recognize that this mailing list is not CRAN, but I was hoping
> someone
> >>> here might know the right way to reach the CRAN team to provide a
> judgment
> >>> on such a request.
> >>>
> >>> Thank you,
> >>> Neal
> >>>
> >>>      [[alternative HTML version deleted]]
> >>>
> >>> ______________________________________________
> >>> R-package-devel using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >> ______________________________________________
> >> R-package-devel using r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list