CRAN Release?

[eitsupi]

Update in 2024: I don't think we will make a CRAN release, please install from R-multiverse.

---

The Rust version of Debian testing will soon be 1.65, which may allow us to build rpolars tuned to build in the R-universe.
(Note that the macOS builder's Rust version may be older than Debian's. PRQL/prqlc-r#94)
https://tracker.debian.org/pkg/rustc
https://qa.debian.org/excuses.php?experimental=1&package=rustc

@sorhawell Could you potentially do a CRAN release?
Probably need to modify build scripts (like #29) and documentation (Of course I would like to contribute to that.).

[sorhawell]

Cool :)

For mac this issue will trigger a warning or error with CRAN check. I likely have to bundle some shared macOS tool or include as a requirement in DESCRIPTION.

Is it allowed on CRAN, not to release on all OS, e.g. skip mac in first round?

Regarding #29
Using CARGO_HOME is very useful to run CHECK in development without recompiling for 30 min. There is something about an environment variable called something like IS_CRAN right? I could disable CARGO_HOME for cran builds then.
I failed to rediscover the exact envvar name in docs.

[eitsupi]

For mac this issue will trigger a warning or error with CRAN check. I likely have to bundle some shared macOS tool or include as a requirement in DESCRIPTION.

I'm sorry I don't understand the whole issue, but are you saying that due to the issue, rpolars can's update polars?
(Currently, the command check is succeeding on the main branch, right?)

There is something about an environment variable called something like IS_CRAN right?

Yes, this must be NOT_CRAN. (See also extendr/rextendr#233)
Note that this is an environment variable name initiated independently by the devtools package, not defined by CRAN.

[sorhawell]

r-lib/rcmdchek does not support to filter errors. Many projects get the same warning on large binary size, which CRAN is not enforcing anyways.

Best advice I could find in issue track is to ignore any warnings in R CMD Check to avoid builds flagged as failed.

I found the practice sub-optimal, as I would not notice my own newly introduced warnings.
Currently I run this filter in workflow to catch all warnings and errors from R CMD Check, which were not already known.

Currently I ignore the binary size warning and the mac dependency warning/error.I don't know how to fix it yet. However, I have never heard of any mac installation except cran Check, where it was actually a problem.

[sorhawell]

@eitsupi Oh sorry I did not reply well to your question.

I'm` sorry I don't understand the whole issue, but are you saying that due to the issue, rpolars can's update polars?

We can update polars just fine. The Mac DLL warning just started at a certain commit when rust-polars introduced some new system calls. I have not solved the warning yet. I suspect that any Mac does support these system calls.

I could immediately try to submit a build to the cran windows test build system and see what we get back. I wonder if there are any limitations on build time.

[eitsupi]

Thanks for the reply.
I don't have macOS and don't have enough knowledge to help solve that problem, but I think there is a possibility that someone else can contribute.

[sorhawell]

@eitsupi
I believe win + mac cran check warnings/fails have disappeared since around R4.3.0 I guess we should be able to make a submission to CRAN parallel to R-universe now :)

[eitsupi]

Grad to hear that!

Debian's Rust version is still 1.63, so we will not be able to do a CRAN release any time soon.

I hope to have the Debian Rust version up by summer and we can get the tasks for the CRAN release done by then.
I created a milestone https://github.com/pola-rs/r-polars/milestone/1.

[sorhawell]

Actually I think we can get away with using Required Rust version >=1.62

[sorhawell]

ohh now I remember that namespace thing that required >= 1.64

[grantmcdermott]

Out of interest, I just peeked at the Debian rustc logs and 1.64 was accepted into the unstable branch earlier this week. See News here: https://packages.qa.debian.org/r/rustc.html

Last time it only took a week for 1.63 to migrate to the testing branch (which is what CRAN uses) after acceptance on unstable. So hopefully not too long now...

[eitsupi]

Last time it only took a week for 1.63 to migrate to the testing branch (which is what CRAN uses) after acceptance on unstable. So hopefully not too long now...

Debian Rust has been completely stuck for the last six months, and it makes little sense to base the schedule on anything earlier than that.....

[eitsupi]

Migration to Rust 1.65 seems to be going well as far as the progress status is seen.
At the earliest, we expect Debian testing to be updated to Rust 1.65 in 5 days.

@sorhawell Any thoughts on submitting to CRAN?

One major issue is that the main branch assumes nightly toolchains and cannot be submitted to CRAN, so I think we need to consider whether to continue to enable simd in the main branch.
-> Resolved 🎉