[R-pkg-devel] Feedback on "Using Rust in CRAN packages"
Simon Urbanek
@|mon@urb@nek @end|ng |rom R-project@org
Fri Jul 14 00:49:17 CEST 2023
Yutani,
[moving back to the original thread, please don't cross-post]
> On Jul 13, 2023, at 3:34 PM, Hiroaki Yutani <yutani.ini using gmail.com> wrote:
>
> Hi Simon,
>
> Thanks for the response. I thought
>
>> download a specific version from a secure site and check that the
> download is the expected code by some sort of checksum
>
> refers to the usual process that's done by Cargo automatically. If it's
> not, I think the policy should have a clear explanation. It seems it's not
> only me who wondered why this policy doesn't mention Cargo.lock at all.
>
as explained. The instructions will be updated to make it clear that "cargo vendor" is the right tool here.
>> it is not expected to use cargo to resolve them from random (possibly
> inaccessible) places
>
> Yes, I agree with you. So, I suggested the possibility of forbidding the Git dependency. Or, do you call crates.io, Rust's official repository, "random places"?
No, as I understand it, the lock file can have arbitrary URLs, that's what I was referring to.
> If CRAN cannot trust even the official one of Rust, why does CRAN have Rust at all?
>
I don't see the connection - if you downloaded something in the past it doesn't mean you will be able to do so in the future. And CRAN has Rust because it sounded like a good idea to allow packages to use it, but I can see that it opened a can of worms that we trying to tame here.
> That said, I agree with your concern about downloading via the Internet in
> general. Downloading is one of the common sources of failure. If you want
> to prevent cargo from downloading any source files, you can enforce adding
> --offline option to "cargo build". While the package author might feel
> unhappy, I think this would make your intent a bit clearer.
>
I'm not a cargo expert, but I thought cargo build --offline is not needed if the dependencies are already vendored? If you think cargo users need more help with the steps, then feel free to propose what the instructions should say (we really assume that the authors know what they are doing).
Cheers,
Simon
More information about the R-package-devel
mailing list