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.
I actually use cargo vendor.
https://github.com/yutannihilation/string2path/blob/main/src/rust/vendor.sh
One thing to note is that, prior to R 4.3.0, the vendored directories hit
the Windows' path limit so I had to put them into a TAR file. I haven't
tested on R 4.3.0, but probably this problem i
> On 13/07/2023, at 2:50 PM, Kevin Ushey wrote:
>
> Package authors could use 'cargo vendor' to include Rust crate sources
> directly in their source R packages. Would that be acceptable?
>
Yes, that is exactly what was suggested in the original thread.
Cheers,
Simon
> Presumedly, the
Package authors could use 'cargo vendor' to include Rust crate sources
directly in their source R packages. Would that be acceptable?
Presumedly, the vendored sources would be built using the versions
specified in an accompanying Cargo.lock as well.
https://doc.rust-lang.org/cargo/commands/cargo-
Yutani,
I'm not quite sure your reading fully matches the intent of the policy.
Cargo.lock is not sufficient, it is expected that the package will provide
*all* the sources, it is not expected to use cargo to resolve them from random
(possibly inaccessible) places. So the package author is expe
Hi,
I'm glad to see CRAN now has its official policy about Rust [1]!
It seems it probably needs some feedback from those who are familiar with
the Rust workflow. I'm not an expert, but let me leave some quick feedback.
This email is sent to the R-package-devel mailing list as well as to cran@~
so
Simon,
It looks like some result mirroring / pushing from your machines to CRAN fell
over. One of my packages, digest 0.6.33, arrived on CRAN about a week ago,
is built almost everywhere (apart from macOS_release_x86_64 stuck at 0.6.32)
but the result page still has nags from the 0.6.31 build f
Dewey,
you will definitely need to include all the necessary sources for your package.
You may want to have a look at the "Using Rust"[1] document linked from the
CRAN policy. I think Go is quite similar to Rust in that sense so you should
use the same approach, i.e. checking for system and use
Dear Sebastian,
Thank you for the advice!
On Mon, 10 Jul 2023 20:08:23 +0200
Sebastian Meyer wrote:
> I think a workaround that currently works for your use case is to use
> \code{fooval.\var{m}} as the label (i.e., wrapped inside \code).
The workaround works well, but I think I agree that \i
Thank you! It seems I needed the refresher on CRAN policy regarding
downloading sources: it seems like the go.sum/go.mod provide sufficient
checksumming to comply with the policy, as you noted (with `go mod
vendor` as a backup if this turns out to not be acceptable). Downloading
Go is probably
Use of precompiled code is not allowed in CRAN. This looks like your package
needs to be distributed elsewhere... e.g. via GitHub.
On July 12, 2023 6:41:11 AM PDT, Russell Almond
wrote:
>I have an R package (RNetica available at
>https://ralmond.r-universe.dev/RNetica and
>https://github.com/
I have an R package (RNetica available at
https://ralmond.r-universe.dev/RNetica and
https://github.com/ralmond/RNetica) which links to a 3rd party library
Netica.dll, so RNetica.dll (built from my C code) calls the 3rd party code.
The config.win script downloads Netica.dll and moves it into th
Dear developers,
CRAN submissions are currently partly not possible due to some
infrastructure issues. Please so NOT contact us if you see "Unpacking
failed. Please make sure the tar.gz was created with R CMD build. [...]".
In addition, processing the CRAN incoming queue of packages (CRAN
pr
13 matches
Mail list logo
