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

[Nic Crane]

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, 
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  wrote:
> >
> > Hi Simon,
> >
> > The email that Neal is referring to was sent by me (this email
> > address) to c...@r-project.org on Mon, 23 Oct 2023.
> >
> > Thanks,
> >
> > Nic
> >
> >
> > On Mon, 29 Jan 2024 at 18:51, Simon Urbanek 
> 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 c...@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.richard...@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
> >>> c...@r-project.org and cran-submissi...@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@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Nic Crane]

Hi Simon,

The email that Neal is referring to was sent by me (this email
address) to c...@r-project.org on Mon, 23 Oct 2023.

Thanks,

Nic


On Mon, 29 Jan 2024 at 18:51, Simon Urbanek  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 c...@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  
> > 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
> > c...@r-project.org and cran-submissi...@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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Simon Urbanek]

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  wrote:
> 
> Hi Simon,
> 
> The email that Neal is referring to was sent by me (this email
> address) to c...@r-project.org on Mon, 23 Oct 2023.
> 
> Thanks,
> 
> Nic
> 
> 
> On Mon, 29 Jan 2024 at 18:51, Simon Urbanek  
> 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 c...@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  
>>> 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
>>> c...@r-project.org and cran-submissi...@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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> 
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Simon Urbanek]

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 c...@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  
> 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
> c...@r-project.org and cran-submissi...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Andrew Robbins via R-package-devel]

Personally haven't had anyone raise an issue with mine downloading 
hash-verified git-tagged tarballs, but I don't know if that's because my 
package is having other issues or if that's because its generally 
acceptable.



-Andrew

On 1/29/2024 9:11 AM, Neal Richardson 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
c...@r-project.org and cran-submissi...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


--
Andrew Robbins
Systems Analyst, Welch Lab
University of Michigan
Department of Computational Medicine and Bioinformatics



OpenPGP_signature.asc
Description: OpenPGP digital signature
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Neal Richardson]

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
c...@r-project.org and cran-submissi...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel