Simin,
Sorry that my question was not clear. Let me clarify.
I think we all agree that "cargo vendor" is the primary option. Since
downloading without explicit permission is not allowed on CRAN in general,
it's reasonable. I'm happy that the instructions will describe it clearly.
But, some R packages have too large dependencies to bundle. In this case,
downloading can be allowed with "the explicit permission of the CRAN team,"
if I understand correctly. For this, I think Cargo's downloading mechanism
satisfy this requirement if (1) all the dependencies are from crates.io and
(2) Cargo.lock exists:
> download a specific version from a secure site and check that the
download is the expected code by some sort of checksum
Because Cargo downloads specific versions recorded in Cargo.lock, verifies
the checksums, and crates.io is the "secure site" that we can rely on as
Hadley wrote.
My question is, does CRAN allow Cargo to download the dependency sources on
CRAN? The policy says:
> So downloading of Rust ‘crates’ will in future require the explicit
permission of the CRAN team
To my eyes, this implies
- CRAN currently allows Cargo's downloading of dependency Rust crates even
without the permission
- CRAN will keep allowing Cargo's downloading if the package author asks
the permission
And, if CRAN doesn't allow it, I (and probably many Rust users) would like
to know why. As I described above, it should satisfy the requirement.
> please don't cross-post
Sorry.
> I thought cargo build --offline is not needed if the dependencies are
already vendored?
Yes, you are right. --offline is not needed if vendering is properly
configured. But, this probably means you have to review the build
configurations in .cargo/config.toml or so, so I just thought it would be
easier for you to check if --offline is specified to the command. This
seems a bit off-topic, so please ignore.
Best,
Yutani
2023年7月14日(金) 9:06 Simon Urbanek <simon.urba...@r-project.org>:
>
>
> > On Jul 14, 2023, at 11:19 AM, Hadley Wickham <h.wick...@gmail.com>
> wrote:
> >
> >>> 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.
> >
> > Can you give a bit more detail about your concerns here? Obviously
> > crates.io isn't some random site on the internet, it's the official
> > repository of the Rust language, supported by the corresponding
> > foundation for the language. To me that makes it feel very much like
> > CRAN, where we can assume if you downloaded something in the past, you
> > can download something in the future.
> >
>
> I was just responding to Yutani's question why we downloaded the Rust
> compilers on CRAN at all. This has really nothing to do with the previous
> discussion which is why I did say "I don't see the connection". Also I
> wasn't talking about crates.io anywhere in my responses in this thread.
> The only thing I wanted to discuss here was that I think the existing Rust
> model ("vendor" into the package sources) seems like a good one to apply
> to Go, but that got somehow hijacked...
>
> Cheers,
> Simon
>
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
