rix: Reproducible Environments with Nix

[b-rodrigues]

trafficstars

Submitting Author Name: Bruno Rodrigues Submitting Author Github Handle: @b-rodrigues Other Package Authors Github handles: @philipp-baumann Repository: https://github.com/b-rodrigues/rix Version submitted: 0.60 Submission type: Standard Editor: @ldecicco-USGS Reviewers: @wdwatkins, @assignUser

Archive: TBD Version accepted: TBD Language: en

---

• Paste the full DESCRIPTION file inside a code block below:

Package: rix
Title: Rix: Reproducible Environments with Nix
Version: 0.6.0
Authors@R: c(
    person("Bruno", "Rodrigues", , "[email protected]", role = c("aut", "cre"),
           comment = c(ORCID = "0000-0002-3211-3689")),
    person("Philipp", "Baumann", , "[email protected]", role = "aut",
           comment = c(ORCID = "0000-0002-3194-8975"))
  )
Description: Provides helper functions to create reproducible development
    environments using the Nix package manager.
License: GPL (>= 3)
URL: https://b-rodrigues.github.io/rix/
BugReports: https://github.com/b-rodrigues/rix
Depends: 
    R (>= 2.10)
Imports: 
    codetools,
    httr,
    jsonlite,
    sys,
    utils
Suggests: 
    knitr,
    rmarkdown,
    testthat
VignetteBuilder: 
    knitr
Config/fusen/version: 0.5.2
Config/testthat/edition: 3
Encoding: UTF-8
LazyData: true
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.3.1

Scope

• Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

  • [ ] data retrieval
  • [ ] data extraction
  • [ ] data munging
  • [ ] data deposition
  • [ ] data validation and testing
  • [x] workflow automation
  • [ ] version control
  • [ ] citation management and bibliometrics
  • [ ] scientific software wrappers
  • [ ] field and lab reproducibility tools
  • [ ] database software bindings
  • [ ] geospatial data
  • [ ] text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences):

The package makes it easy to define default.nix files which can then be use by the Nix package manager to build a reproducible development environment. This is especially useful to make workflows completely reproducible.

• Who is the target audience and what are scientific applications of this package?

This package will be useful to anyone with very strict reproducibility requirements.

• Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

Not quite: to replace what {rix} provides one would need to combine Docker and {renv} or {groundhog}.

• (If applicable) Does your package comply with our guidance around Ethics, Data Privacy and Human Subjects Research?

Not applicable.

• If you made a pre-submission inquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

https://github.com/ropensci/software-review/issues/624

@jhollist @mpadge

• Explain reasons for any pkgcheck items which your package is unable to pass.

We are unable to have the coverage of 75%. This is due to several issues:

1. Some tests requires Nix to run. For these tests, we have a "skip if nix is not available" test.
2. Some tests make {covr} completely fail, even if they have the skip_on_covr() function, but on only on GA. On our computers, covr::package_coverage() runs and these tests are successfully skipped.
3. We have several snapshot tests, and these simply seem to be ignored by covr.

We have 26 tests, which all pass on different configurations: on Ubuntu, macOS and Windows, with or without Nix available (some tests get skipped if Nix is not available) and whether R itself is installed with Nix as well, or not (in other words, through the usual means for the operating system in use).

Because of these issues, our coverage is quite low:

> rix Coverage: 10.87%
R/get_latest.R: 0.00%
R/nix_build.R: 0.00%
R/rix.R: 0.00%
R/tar_nix_ga.R: 0.00%
R/with_nix.R: 0.68%
R/rix_init.R: 2.84%
R/detect_os.R: 28.57%
R/fetchgit.R: 90.00%
R/find_rev.R: 92.31%
R/available_r.R: 100.00%
R/detect_versions.R: 100.00%
R/get_sri_hash_deps.R: 100.00%

but if our snapshot tests (for the functions rix(), and tar_nix_ga()) would not be ignored, and if covr would successfully run the tests for with_nix(), our coverage would be more than 50%, we think. Some functions are very difficult to test, for example get_latest(), which gets the latest commit hash of the nixpkgs github repository.

Technical checks

Confirm each of the following by checking the box.

• [x] I have read the rOpenSci packaging guide.
• [x] I have read the author guide and I expect to maintain this package for at least 2 years or to find a replacement.

This package:

• [x] does not violate the Terms of Service of any service it interacts with.
• [x] has a CRAN and OSI accepted license.
• [x] contains a README with instructions for installing the development version.
• [x] includes documentation with examples for all functions, created with roxygen2.
• [x] contains a vignette with examples of its essential functions and uses.
• [x] has a test suite.
• [x] has continuous integration, including reporting of test coverage.

Publication options

• [x] Do you intend for this package to go on CRAN?

• [ ] Do you intend for this package to go on Bioconductor?

• [ ] Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

• [ ] The package is novel and will be of interest to the broad readership of the journal.
• [ ] The manuscript describing the package is no longer than 3000 words.
• [ ] You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
• (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
• (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
• (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

• [x] I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

[ropensci-review-bot]

Thanks for submitting to rOpenSci, our editors and @ropensci-review-bot will reply soon. Type @ropensci-review-bot help for help.

[ropensci-review-bot]

:rocket:

Editor check started

:wave:

[ropensci-review-bot]

Checks for rix (v0.6.0)

git hash: e7b673cb

• :heavy_check_mark: Package name is available
• :heavy_check_mark: has a 'codemeta.json' file.
• :heavy_check_mark: has a 'contributing' file.
• :heavy_check_mark: uses 'roxygen2'.
• :heavy_check_mark: 'DESCRIPTION' has a URL field.
• :heavy_check_mark: 'DESCRIPTION' has a BugReports field.
• :heavy_check_mark: Package has at least one HTML vignette
• :heavy_check_mark: All functions have examples.
• :heavy_check_mark: Package has continuous integration checks.
• :heavy_multiplication_x: Package coverage failed
• :heavy_check_mark: R CMD check found no errors.
• :heavy_check_mark: R CMD check found no warnings.

Important: All failing checks above must be addressed prior to proceeding

Package License: GPL (>= 3)

---

1. Package Dependencies

Details of Package Dependency Usage (click to open)

The table below tallies all function calls to all packages ('ncalls'), both internal (r-base + recommended, along with the package itself), and external (imported and suggested packages). 'NA' values indicate packages to which no identified calls to R functions could be found. Note that these results are generated by an automated code-tagging system which may not be entirely accurate.

type	package	ncalls
internal	base	199
internal	rix	66
imports	codetools	5
imports	httr	4
imports	utils	3
imports	sys	2
imports	jsonlite	1
suggests	knitr	NA
suggests	rmarkdown	NA
suggests	testthat	NA
linking_to	NA	NA

Click below for tallies of functions used in each package. Locations of each call within this package may be generated locally by running 's <- pkgstats::pkgstats(<path/to/repo>)', and examining the 'external_calls' table.

base

lapply (15), Sys.getenv (14), is.null (11), paste0 (9), Filter (8), file.path (7), list (7), names (7), for (6), get (6), grep (6), paste (6), seq_along (6), unlist (6), vapply (6), all (4), c (4), grepl (4), if (4), nzchar (4), args (3), character (3), emptyenv (3), switch (3), any (2), as.list (2), call (2), environmentName (2), getOption (2), gsub (2), is.function (2), new.env (2), setdiff (2), Sys.which (2), url (2), as.character (1), as.name (1), bquote (1), deparse (1), do.call (1), file (1), file.exists (1), formals (1), format (1), identical (1), length (1), logical (1), Map (1), match (1), match.call (1), normalizePath (1), readRDS (1), source (1), split (1), strsplit (1), Sys.info (1), Sys.time (1), system.file (1), tempdir (1), unname (1)

rix

classify_globals (3), deparse_chr1 (3), get_sri_hash_deps (3), detect_versions (2), find_rev (2), get_globals_exprs (2), get_rPackages (2), get_rprofile_text (2), is_nix_rsession (2), is_rstudio_session (2), nix_build_exit_msg (2), set_nix_path (2), where (2), available_r (1), check_expr (1), create_shell_nix (1), detect_os (1), fetchgit (1), fetchgits (1), fetchpkgs (1), fetchzip (1), fetchzips (1), fix_ld_library_path (1), generate_git_archived_packages (1), generate_header (1), generate_locale_archive (1), generate_locale_variables (1), generate_rix_call (1), generate_rpkgs (1), generate_rstudio_pkgs (1), generate_shell (1), generate_system_pkgs (1), generate_tex_pkgs (1), get_expr_extra_pkgs (1), get_latest (1), get_system_pkgs (1), is_empty (1), is_integerish (1), message_rprofile (1), nix_build (1), nix_build_installed (1), nix_rprofile (1), nix_shell_available (1), poll_sys_proc_nonblocking (1), quote_rnix (1), recurse_find_check_globals (1), serialize_globals (1), serialize_pkgs (1), with_assign_vec_call (1), with_assign_vecnames_call (1)

codetools

findGlobals (3), checkUsage (2)

httr

GET (3), content (1)

utils

timestamp (2), packageVersion (1)

sys

exec_status (2)

jsonlite

fromJSON (1)

---

2. Statistical Properties

This package features some noteworthy statistical properties which may need to be clarified by a handling editor prior to progressing.

Details of statistical properties (click to open)

The package has:

• code in R (100% in 14 files) and
• 2 authors
• 12 vignettes
• 1 internal data file
• 5 imported packages
• 6 exported functions (median 66 lines of code)
• 104 non-exported functions in R (median 11 lines of code)

---

Statistical properties of package structure as distributional percentiles in relation to all current CRAN packages The following terminology is used:

• loc = "Lines of Code"
• fn = "function"
• exp/not_exp = exported / not exported

All parameters are explained as tooltips in the locally-rendered HTML version of this report generated by the checks_to_markdown() function

The final measure (fn_call_network_size) is the total number of calls between functions (in R), or more abstract relationships between code objects in other languages. Values are flagged as "noteworthy" when they lie in the upper or lower 5th percentile.

measure	value	percentile	noteworthy
files_R	14	70.8
files_vignettes	12	99.6
files_tests	18	95.7
loc_R	1250	73.8
loc_vignettes	1689	96.2	TRUE
loc_tests	639	79.6
num_vignettes	12	99.9	TRUE
data_size_total	1318	61.2
data_size_median	1318	65.8
n_fns_r	110	78.8
n_fns_r_exported	6	29.1
n_fns_r_not_exported	104	84.5
n_fns_per_file_r	5	70.1
num_params_per_fn	4	67.3
loc_per_fn_r	12	36.1
loc_per_fn_r_exp	66	85.8
loc_per_fn_r_not_exp	11	35.4
rel_whitespace_R	20	76.4
rel_whitespace_vignettes	29	97.1	TRUE
rel_whitespace_tests	21	78.5
doclines_per_fn_exp	66	77.6
doclines_per_fn_not_exp	0	0.0	TRUE
fn_call_network_size	79	75.2

---

2a. Network visualisation

Click to see the interactive network visualisation of calls between objects in package

---

3. goodpractice and other checks

Details of goodpractice checks (click to open)

3a. Continuous Integration Badges

GitHub Workflow Results

id	name	conclusion	sha	run_number	date
7802080928	devtools-tests-via-r-nix	success	e7b673	69	2024-02-06
7802080935	nix-builder	success	e7b673	385	2024-02-06
7802119374	pages build and deployment	success	ef12c6	276	2024-02-06
7802080938	pkgdown	success	e7b673	532	2024-02-06
7802080934	R-CMD-check	success	e7b673	528	2024-02-06
7801340546	ropensci-pkgcheck	failure	27a828	64	2024-02-06
7802080931	tests-r-via-system	success	e7b673	66	2024-02-06

---

3b. goodpractice results

R CMD check with rcmdcheck

R CMD check generated the following note:

1. checking package subdirectories ... NOTE Problems with news in ‘NEWS.md’: Cannot extract version info from the following section titles: rix (development version)

Test coverage with covr

ERROR: Test Coverage Failed

Cyclocomplexity with cyclocomp

The following functions have cyclocomplexity >= 15:

function	cyclocomplexity
with_nix	27
rix	22

Static code analyses with lintr

lintr found the following 108 potential issues:

message	number of times
Avoid library() and require() calls in packages	19
Lines should not be more than 80 characters.	87
unexpected '/'	1
Use <-, not =, for assignment.	1

---

Package Versions

package	version
pkgstats	0.1.3.9
pkgcheck	0.1.2.14

---

Editor-in-Chief Instructions:

Processing may not proceed until the items marked with :heavy_multiplication_x: have been resolved.

[ldecicco-USGS]

@ropensci-review-bot assign @ldecicco-USGS as editor

[ropensci-review-bot]

I'm sorry human, I don't understand that. You can see what commands I support by typing:

@ropensci-review-bot help

[ldecicco-USGS]

@ropensci-review-bot assign @ldecicco-USGS as editor

[ropensci-review-bot]

Assigned! @ldecicco-USGS is now the editor

[ldecicco-USGS]

Editor checks:

• [x] Documentation: The package has sufficient documentation available online (README, pkgdown docs) to allow for an assessment of functionality and scope without installing the package. In particular,
  • [x] Is the case for the package well made?
  • [x] Is the reference index page clear (grouped by topic if necessary)?
  • [x] Are vignettes readable, sufficiently detailed and not just perfunctory?
• [x] Fit: The package meets criteria for fit and overlap.
• [x] Installation instructions: Are installation instructions clear enough for human users?
• [x] Tests: If the package has some interactivity / HTTP / plot production etc. are the tests using state-of-the-art tooling?
• [x] Contributing information: Is the documentation for contribution clear enough e.g. tokens for tests, playgrounds?
• [x] License: The package has a CRAN or OSI accepted license.
• [x] Project management: Are the issue and PR trackers in a good shape, e.g. are there outstanding bugs, is it clear when feature requests are meant to be tackled?

---

Editor comments

Looks good! I'll begin searching for editors.

[ldecicco-USGS]

@ropensci-review-bot seeking reviewers

[ropensci-review-bot]

Please add this badge to the README of your package repository:

[![Status at rOpenSci Software Peer Review](https://badges.ropensci.org/625_status.svg)](https://github.com/ropensci/software-review/issues/625)

Furthermore, if your package does not have a NEWS.md file yet, please create one to capture the changes made during the review process. See https://devguide.ropensci.org/releasing.html#news

[b-rodrigues]

Please add this badge to the README of your package repository:

done with: https://github.com/b-rodrigues/rix/commit/859fd18524cf7c9951d0c95af1ac36cc23b0623c

[ldecicco-USGS]

@ropensci-review-bot assign @wdwatkins as reviewer

[ropensci-review-bot]

@wdwatkins added to the reviewers list. Review due date is 2024-03-06. Thanks @wdwatkins for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

[ropensci-review-bot]

@wdwatkins: If you haven't done so, please fill this form for us to update our reviewers records.

[ldecicco-USGS]

@ropensci-review-bot assign @assignUser as reviewer

[ropensci-review-bot]

@assignUser added to the reviewers list. Review due date is 2024-03-11. Thanks @assignUser for accepting to review! Please refer to our reviewer guide.

rOpenSci’s community is our best asset. We aim for reviews to be open, non-adversarial, and focused on improving software quality. Be respectful and kind! See our reviewers guide and code of conduct for more.

[ropensci-review-bot]

@assignUser: If you haven't done so, please fill this form for us to update our reviewers records.

[ropensci-review-bot]

:calendar: @wdwatkins you have 2 days left before the due date for your review (2024-03-06).

[wdwatkins]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• Briefly describe any working relationship you have (had) with the package authors.
• [x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• [x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
• [x] Installation instructions: for the development version of package and any non-standard dependencies in README
• [x] Vignette(s): demonstrating major functionality that runs successfully locally
• [x] Function Documentation: for all exported functions
• [x] Examples: (that run successfully locally) for all exported functions
• [x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

• [x] Installation: Installation succeeds as documented.
• [x] Functionality: Any functional claims of the software have been confirmed.
• [x] Performance: Any performance claims of the software have been confirmed.
• [x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
• [x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing:6

• [x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

---

Review Comments

Due to my organization's IT policies, I can only run nix in a Docker container,so all my experimenting with the actual nix libraries is done there. I can use the CLI to interact with nix,though its a bit awkward without other things installed (e.g. R). I was able to generate the default.nix files with rix, then copy them into the container to build them with shell commands.

You may need to update the nix install command at some point, just be aware if that changes

Good selection of vignettes, help files are complete.

I also found your "What is nix" blog post particularly helpful for understanding what was actually happening under the hood. It seems likely to me that a good portion of your users will also be using nix for the first time, so it is worth making sure you explain or link out to explanations of how nix itself works at an intuitive level, in the interest of usability.

From goodpractice results

Is there a reason for using = here R/with_nix.R:564:13?

code comments

I see a couple 'list versions' functions rely on a stored data file. Is there a way to get this information directly from the nix archive so you don't need to keep that up to date?

There are a fair number of internal functions that don't have inputs/outputs documented, I would suggest documenting those for your own/future maintainer's benefit down the road.

Also, several todos still in comments.

test comments

Seems like get_latest.R could be tested at least that it doesn't error and returns a hash, outside of environments where web service requests would fail?

Re: coverage—just to make sure I understand, the 25% coverage value is ignoring the tests that actually run nix commands since you would need an environment with nix installed to run them, which you don't get in CRAN or other non-containerized environments? It seems like it should be possible to make a Docker container with both R and nix installed to get a more realistic test environment, but maybe you've done this already.

[ropensci-review-bot]

:calendar: @assignUser you have 2 days left before the due date for your review (2024-03-11).

[assignUser]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• Briefly describe any working relationship you have (had) with the package authors.
• [x] As the reviewer I confirm that there are no conflicts of interest for me to review this work (if you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• [x] A statement of need: clearly stating problems the software is designed to solve and its target audience in README
• [x] Installation instructions: for the development version of package and any non-standard dependencies in README
• [x] Vignette(s): demonstrating major functionality that runs successfully locally
• [x] Function Documentation: for all exported functions
• [x] Examples: (that run successfully locally) for all exported functions
• [x] Community guidelines: including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

• [x] Installation: Installation succeeds as documented.
• [x] Functionality: Any functional claims of the software been confirmed.
• [x] Performance: Any performance claims of the software been confirmed.
• [x] Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
• [x] Packaging guidelines: The package conforms to the rOpenSci packaging guidelines.

Estimated hours spent reviewing: 6

• [x] Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

---

Review Comments

{rix} is a very interesting package that will allow R developers to make use of nix powerful features without having to learn (much) of its arcane secrets :mage: . For me personally it was a great opportunity to finally get to know 'nix' (special thanks for pointing to the DS installer as I have previously destroyed a shell env via half-removed nix :grin:).

While it is afaik not required by rOpenSci, I would recommend to change the default branch from 'master' to 'main'. It's a small, easy change that is well supported by GitHub but is quite meaningful.

Documentation

Overall the documentation is very good and covers basic as well as advanced features of the package and points to a plethora of external resources about nix. The README especially guides both beginner and advanced users and points to the specific useful further materials. I have made a few notes while reading/following along with the vignettes that I will list as bullet points for brevity. These are all what I would consider 'nits'/nice to haves and not show stoppers.

• All vignettes start with a code block with a library(rix) call, which seems uneccessary (-> echo=False).
• The 'numbering' of the vignettes being 'hardcoded' in the title is a bit unusual and I personally would remove it as the vignettes all link to their respective follow up vignettes (well except C 'Using rix'). If this is done to make sure they appear in a certain order in the pkgdown menu: this can be controlled via the _pkgdown.yml.
• Getting Started: more paragraphs would make for a smoother read of the first block of text.
• b2: 'generates R expressions' -> 'nix expressions'?
• d2: Should the link to the nix package search by default be to the stable rather than unstable channel?
• e: I tried using nvim with lsp in an nix shell and that crashed but I think that might be due to my use of mason, which provides a separate R env for the languageserver, clashing with nix. I haven't done any further investigations for now.
• d1: It's imo superflous to require both branch and commit as a commit is unique to a repo and not a branch so the additional info of branch is not necessary. Branch could be resolved to the lates commit on that branch (not entireliy inline with literate programming but useful when working against a quickly changing internal pkg?). It would also be nice to add a short hand similar to {pak} ala owner/repo@ref (ref = tag, branch or commit)
• Remote dependencies: I think {rix} should provide functionality to install packages with remote dependencies not found in nixpkgs. While it might be relatively rare case for packages publicly hosted on GitHub I think it is much less unusual for companies to have a number of internal packages that also depend on each other. The issue with no default way to know which commit could be solved by printing a warning and maybe the required shorthand to explicitly add the pkg to rix().
• The developers vignettes are both quite short and could be combined into one.

Code

• I agree with @wdwatkins regarding the test coverage.

• There is a probably unintentional partial match in flag_git_archive: In cran_pkgs$archive : partial match of 'archive' to 'archive_pkgs'

• I like the use of {fledge} but personally don't think {fusen} is the right choice for a technically advanced package like {rix}. It is of course preference and up to you but I think {fusen} changes the established workflow of an R package dev quite a bit. I see how it can lower the bar for people to get started with creating packages and that's great. But I think in this case the people that are likely going to contribute (experienced devs) might not do it if that means they have to spend time getting used to {fusen} vs. just adding a quick patch. (I certainly looked through R/ and not dev/)

• The two main functions rix and with_rix and some of the helper functions are quite long and would benefit from some refactoring (a comment hinting which if() your closing is a good pointer that some refactoring is in order :wink: ). This would also remove duplicate code (e.g. in serialize_globals)

• The large error message in with_rix will never be reached due to the preceding stopifnot, maybe combine the two?

• I was surprised that you are not using {rlang} and quosures, it has been a while since I have used them but I would think they would be a good fit here. (but maybe not, it's been a while since I have used them 'under the hood')

• GHAs are my specialty so some extended notes on extdata/run-pipeline.yml (most of this applies in general as well):

  • Please explicitly add the contents: write permission. This is technically not required as the token has the correct permisson but it is best practice to minimise token permissions.
    • You should also do this on the workflows in .github/workflows/ with the minimal permissions each (e.g. contents: read)
  • Always use at least tags for actions for stability, in an action that has write permission I would even highly recommend to explicitly use a commit hash. That ensures that even a malicous take over of one of the action repos does not allow a third-party to run code in your repo. Github's dependabot can handle updating shas and tags.
  • Make sure tags/hashes are updated regularly (actions/checkout is at v4 but v2 is used in the workflow).
  • secrets should always be assigned to envvars as close to where they are used as possible (usually step env:) and not for the entire workflow.
  • I would recommend to use an explicit output instead of continue-on-error as that still creates a big red error message in the job summary.

• It seems like the codetools::check is run quite a lot, I assume it's to make debugging easier?

• with_nix is very verbose with ~ a terminal length of 'preamble' output of checks etc., I think a 'quite' option would be nice when running it repeatedly.

• 'hidden' bindings like {arrow}'s dplyr bindings are not forwarded to the nix shell with_nix (the workaround of explicitly calling some function in the expression you want to run is probably way easier than an actual fix, but I don't really know as I am mostly concerned with arrow's build system^^):

  library(rix)
  library(arrow)
  library(dplyr)
  arrow_cars <- arrow_table(cars)
  arrow_test <- function() {
    arrow_cars %>% 
      dplyr::filter(speed > 10)
  }
  with_nix(arrow_test())
  

  => Serializing package(s) required to run expr: dplyr

[b-rodrigues]

Thank you very much for your reviews!

Until when do we have to address them?

[ldecicco-USGS]

Thanks so much @wdwatkins and @assignUser ! There's no specific due date for a response. The sooner you respond, the fresher the comments are in the reviewers' mind.

[ldecicco-USGS]

@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/625#issuecomment-1987436941 time 6

[ropensci-review-bot]

Logged review for assignUser (hours: 6)

[ldecicco-USGS]

@ropensci-review-bot submit review https://github.com/ropensci/software-review/issues/625#issuecomment-1979894880 time 6

[ropensci-review-bot]

Logged review for wdwatkins (hours: 6)

[philipp-baumann]

Thanks a lot @wdwatkins and @assignUser also from my side for the encouraging review feedback and concrete tips to improve {rix}, and @ldecicco-USGS for guiding the review process.

[ropensci-review-bot]

@b-rodrigues, @philipp-baumann: please post your response with @ropensci-review-bot submit response <url to issue comment> if you haven't done so already (this is an automatic reminder).

Here's the author guide for response. https://devguide.ropensci.org/authors-guide.html

[b-rodrigues]

Sorry we've been slow to respond, but you'll hear from us this week!