Mossa,
> On Mar 2, 2025, at 11:45 PM, Mossa Merhi Reimert <mo...@sund.ku.dk> wrote: > > There has been very little engagement with the issue I referred to. If it was > decided that this “check” ought to be part of the default checks for R, then > that could have been written to us. Either on the bugs.r-project.org or the > proposed patch. Before we talk about anything else, it does seem very strange > that we cannot get a reasonable dialogue going. > I don't see anything from you on this list - your first engagement was yesterday. I have no idea what you refer to as "us" and what makes you think you should have been notified if no one heard from you before. A start of any engagement is to start communication, so here we are, perhaps not the most fortunate way to start off, but we have a discussion and there is hope. > I would like to say that the R/Rust community has grown substantially. From > my end, there are 3 bindings project, extendr, savvy, and roxido. Then, there > are now many rust-based packages on CRAN, see this most recent compiled list > https://github.com/nanxstats/r-rust-pkgs. There is also proof-of-concept > https://github.com/r-rust/hellorust that integrates `cargo`, rust’s official > build system, with R’s package build system, and > https://github.com/extendr/hellorustc, which showcases how Rust compiler > could be directly linked with R’s package system. > I think this part of the problem - there is no systematic rust support, so each package author does something differently. As much as it is nice to have the freedom to have many different implementation of the same thing, I would argue that in cases like language support it makes more sense to combine the effort into one solution (after everyone experimented and gained enough experience) that is easy to manage and is well maintained. This is what happened to most mature languages such as C++, Java and Python. That would avoid the "hacks" in place today (I'm referring to the check). > Let me say, that the current R CMD check is not meant to be “helpful”. When > a package is built, `cargo` tells the user “Downloading crates”. Thus, this > information is already conveyed to the user. > > Personally, I do wish we could debate this requirement further. I do not > believe that having R-packages on CRAN vendor rust dependencies as a good > policy. Download statistics is a success metric of a given r-package and rust > packages. By insisting on vendoring, and thus side-stepping `cargo` / > crates.io, we are robbing upstream authors of their download-numbers. I do > not think such policy is honourable. > You are jumping issues here: as I said before this has nothing to do with CRAN. So let us first take CRAN out of the picture and talk about the check. The check does two things: a) it checks that the package correctly declares rust dependency and b) checks whether the package uses 3rd party dynamic downloads. Since the "R"ust community has yet to come up with any systematic rust support, both seem very reasonable checks. We want to know if a package requires rust by checking the DESCRIPTION file alone so the user can make an informed decision whether they want (or even can) use the package. It is also important to know if a package can accesses 3rd party resources online. Due to rising security threats it is increasingly common to not allow analytics machines to have access to the Internet so sensitive data cannot be leaked. It also opens the can of legality as the resulting software may not adhere to the license of the package and there is no guarantee that the user will still have the license. Moreover, reproducibility is very important to R users so it should be possible to reproduce the installation - which excludes 3rd party distributed systems which don't have any such guarantees unless they provide a way to fully vendor dependencies. So, in short, there are many reasons why the user should know about the things checked so they can make informed decisions. Whether this is the best way to signal that is up for debate. Your argument is that the important reason is a popularity contest based on download statistics. I would argue that it is a very weak reason, since vast majority of R users does not use source installations to install packages, so there is no "robbing" of upstream authors - the statistics don't reflect real usage anyway. If you want to propose improvements to the check, I'm sure it would be appreciated, but putting it behind --as-cran doesn't seem the right approach nor does that solve the problem in any way as the issues are not CRAN-specifc. I would think that some proposal to declare rust requirements (incl. toolchain) and have declared a way to vendor dependencies to address off-line install, licensing and security issues uniformly for rust packages would be steps in the right direction. > While C/C++ do not have official package repositories, it could be thought > of, as fair game, to have CRAN act as a pseudo package manager for C/C++ > libraries. > I’m not going to argue for or against this part. > > There are many objections from the CRAN side to all things related to Rust. I > don’t want to open multiple topics in the same thread. > But there is plenty to bring up. And I had hoped we could talk this little > issue through, before embarking on a larger discussion. > I do not appreciate the “random demands” comment, as this is not a demand, > nor is it random. > I have inquired my end of the community for suggestions > to compile a larger proposal, but then I was afraid that this would be > perceived as a big, bulky demand. > > Rust is not C/C++/Java, and the support for Rust cannot look like the support > for these languages. > Why not? They all require compilers, ways to deal with dependencies and produce binaries - so does Rust. It's just one of many similar languages. The key is to have proper support instead of having each package deal with the complexities alone. Cheers, Simon ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
