[R-pkg-devel] About the CRAN policy on downloading pre-compiled binary
On 7/27/22 09:03, Hiroaki Yutani wrote:
Thank you. I'll read the policy again more carefully.
but you are not downloading sources.
The case is that, I include the Rust source code, but since the CRAN's Windows & macOS machines don't have the Rust compiler installed, there's no choice but to download the pre-compiled binary (other than downloading the Rust compiler).
I'd say at least check whether the compiler is present (during package installation), and use it if it is. Only if you want to download binaries as a last resort when it isn't, consult that first with the CRAN team. Perhaps it could also be a hard dependency for installing the package, and perhaps Rust compiler would be installed on the CRAN machines. I think it is better not to hard-code which software is installed on the CRAN systems, because that may change and because different software may be installed on user machines. However, on Windows, it is ok to expect that say Rtools42 is available when building packages for R 4.2 (yet Rtools42 don't have a rust compiler, so it doesn't help you here). Right, downloading the source code of the Rust compiler and building it seems a bit too resource intensive and then, a bit too much if multiple R packages need it. Ideally the compiler will be installed and the R source packages will really be source packages (no binaries).
In either case, of course if there is anything unclear in an email from CRAN, you can simply respond to that and ask.
Thanks, I already responded with what I wrote above, so I hope I can get the reply. But, since the CRAN team might be on vacation now, I wanted to get some advice on this mailing list. Thanks for your help!
No problem, just please only regard it as my advice. Best Tomas
Best,
Yutani
2022?7?27?(?) 15:08 Tomas Kalibera <tomas.kalibera at gmail.com>:
On 7/27/22 00:30, Hiroaki Yutani wrote:
> Hi,
>
> Recently I got the following email from the CRAN maintainer about my
> package, string2path[1].
>
> However, I do ensure the binary is the pinned version and verify
if the
> hash matches with the embedded one in the DESCRIPTION [2][3]. In
case of a
> mismatch, the build fails. So, this mechanism should ensure that
I (or
> anyone) cannot change the version of the binary without actually
> resubmitting to CRAN.
Please see the policy cited. Ensuring that the download is of a fixed
version refers to the sources (which can be downloaded under the
conditions mentioned).
Downloading binaries are only a last resort option and requires the
agreement of the CRAN team in the first place.
> I believe this complies with the CRAN policy (except for not
clearing the
> authorship and copyright). Is there anything I have to address
to prove I
> do "ensure that the download is of a fixed version"? Any
suggestions are
> welcome.
My understanding from your email is you are ensuring a fixed version
download, and with most projects you could probably do even less
(simply
hardcode a URL which includes a specific version of the sources if
that
is stable for the project), but you are not downloading sources.
In either case, of course if there is anything unclear in an email
from
CRAN, you can simply respond to that and ask.
Best
Tomas
>
> The CRAN policy stipulates
>> "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."
>>
>> and we have recently seen an instance of a rust-using package whose
>> check output changed because what it downloaded had changed.? CRAN
>> checking is not set up for that (for example, macOS checks are
done once
>> only for each version).
>>
>> Whilst investigating, the Windows' maintainers found that
binary libs
>> were being downloaded.? And subsequently I found that salso,
string2path
>> and ymd are downloading compiled code on Intel macOS.
>>
>> Also. make sure that the authorship and copyright of code you
download
>> (and hence include in the package) is clear from the
DESCRIPTION file.
>> as required by the CRAN policy.
>>
> Best,
> Hiroaki Yutani
>
> [1]: https://cran.r-project.org/package=string2path
> [2]:
>
> [3]:
>
>
>? ? ? ?[[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel