-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds CRAN compliance helpers and vignette #320
Conversation
…w has a snapshot for the invisibly returned data frame instead. This should not change (unless order is not preserved)
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
Co-authored-by: Ilia Kosenkov <[email protected]>
@Ilia-Kosenkov I cannot figure out what the error is with these snapshot tests for testing vendoring output. @CGMossa was able to pull the branch, run the tests, and they all passed. Do you have any idea what might be causing the failure? I'm tempted to remove to test all together to appease the CI gods. |
Ok let me check |
Which is yet different than the CI errors 🙈 ! Thank you for testing |
Maybe you can extract vendored packages (if I udnerstand your logic) using this regex? |
Second attempt to fix snapshot test on CI
@Ilia-Kosenkov your changes have fixed CI! I've added a note to NEWS.md as well. |
I'd like to revisit this PR. I used this fork to publish {arcpbf} to CRAN. Using these functions has made it very easy to publish extendr packages to CRAN. There was no back and forth about the use of Rust in this package, no back and forth about the build or compilation process etc. I think making it easy to publish extendr packages to CRAN is the best way to make this project widely useful and interesting. Please let me know what is needed to merge this PR. |
Hey @JosiahParry , what' the status of this PR? |
What do you need from me to merge this PR? I've been using it myself for cran publications. |
Tests are failing due to version mismatch, can you pull it locally and run tests - it should tell you which snapshot is wrong. |
And add a reference to your Pr in News.md, I think it is missing |
Cool sounds good! I'll appease PR gods tomorrow-ish and update news to get this through! |
Looks solid! If you have no more changes to make @JosiahParry , should we merge it? |
No more changes from me at this time :) |
This PR superceds #313. The purpose of this PR is create a pathforward for developers who wish to publish extendr packages on CRAN. It is based on prqlr and my experience publishing rsgeo to CRAN.
The PR adds:
use_cran_defaults()
which addsconfigure
andconfigure.win
files, modifiesMakevars
andMakevars.win
to use CRAN requirementsvendor_pkgs()
which vendors crates appropriatelycargo generate-lockfile
for brand new packages without aCargo.lock
filevendor-config.toml
vignettes/articles/cran-compliance.Rmd
which describes the process for making R packages CRAN compliant.It does not add functionality to document crate authors. rsgeo does not do this and has not been problematic in getting the package published—though it may in the future, I am unsure.
Nonetheless, I used these functions to publish rsgeo and it has been successful. This PR provides minimal funcitonality to provide a path forward towards CRAN compliant packages in an opt-in manner.
Follow up tasks
SystemRequirements
field #310SystemRequirements
field #310 is required. Initially, i added it as part of this PR but I believe it should be for all new extendr packages not just CRAN ones