grumpy. Read NumPy .npy and .npz files in R.

[Bisaloo]

Submitting Author Name: Hugo Gruson
Submitting Author Github Handle: @Bisaloo
Repository: https://github.com/Bisaloo/grumpy
Version submitted: 0.1.1.9000
Submission type: Standard
Editor: @njtierney
Reviewers: TBD

Archive: TBD
Version accepted: TBD
Language: en

---

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

Package: grumpy
Title: Read 'NumPy' '.npy' and '.npz' Files
Version: 0.1.1.9000
Authors@R: c(
    person("Hugo", "Gruson", , "hugo.gruson+R@normalesup.org", role = c("aut", "cre", "cph"),
           comment = c(ORCID = "0000-0002-4094-1476")),
    person("Mike", "Smith", role = c("aut", "cph"),
           comment = c("Original author of portions of the C code migrated from the Rarr package")),
        person("German Network for Bioinformatics Infrastructure - de.NBI", role = "fnd")
    )
Description: Lightweight way to read 'NumPy' '.npy' and '.npz' files in R. All data types supported
    by 'NumPy', with all sizes (converted internally to R native size), both C and 'Fortran' order,
    and any shape, up to an arbitrary number of dimensions, are supported.
License: MIT + file LICENSE
Encoding: UTF-8
Roxygen: list(markdown = TRUE)
Suggests: 
    quarto,
    testthat (>= 3.0.0)
VignetteBuilder: quarto
Config/testthat/edition: 3
URL: https://hugogruson.fr/grumpy/, https://github.com/Bisaloo/grumpy
BugReports: https://github.com/Bisaloo/grumpy/issues
Imports: 
    jsonlite
Config/roxygen2/version: 8.0.0
Depends: 
    R (>= 4.2.0)

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
  • workflow automation
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • translation
  • rOpenSci internal tools

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

This package allows reading data produced by numpy, or the numerous python libraries depending on numpy, in R. This is critical to ensure interoperability of R and python, and to allow retrieval of data already saved into npy format.

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

Anyone who has hybrid R/python pipelines, or who has collaborators using python. This allows to seamlessly exchange data between both languages (although higher-performance fully interoperable formats should be preferred where available). This is for example very common in molecular biology.

This is also a precious tool to open previously saved and published / archived datasets. See for example zenodo.org/search?q=&f=file_type%3Anpy&l=list&p=1&s=10&sort=newest.

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

• cran.r-project.org/package=RcppCNPy but it supports a subset of cases (types can only match R natives types, so not int16, float32, etc., and the maximum number of array dimensions is 3).

• cran.r-project.org/package=reticulate but it is not specifically designed and thus not specifically optimized for this task (extra copies in memory, slower, less flexibility in output format)

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

NA

• 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.

#772

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

Technical checks

Confirm each of the following by checking the box.

• I have read the rOpenSci packaging guide.
• 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:

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

Use of Generative AI

• Generative AI tools were used to produce some of the material in this submission.

The package was originally manually written in R. Some C code was then manually migrated from the Rarr package. After this, some minimal conversion of specific steps from R to C was done (e.g., Bisaloo/grumpy@17a80c5) with Posit Assistant in Positron. The agent was guided through it step by step and the entire, small, diff was reviewed before pushing.

Publication options

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

This package has already been submitted to 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

• 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]

🚀

Editor check started

👋

[ropensci-review-bot]

Five most similar rOpenSci packages

• ijtiff 'Comprehensive TIFF I/O with Full Support for 'ImageJ' TIFF Files' (v3.2.0, released 2026-01-26)
• tiler 'Create Geographic and Non-Geographic Map Tiles' (v0.3.2, released 2024-09-11)
• datefixR 'Standardize Dates in Different Formats or with Missing Data' (v2.0.1, released 2026-04-27)
• geojsonio 'Convert Data from and to 'GeoJSON' or 'TopoJSON'' (v0.11.3, released 2023-09-06)
• fastMatMR 'High-Performance Matrix Market File Operations' (v1.2.7, released 2026-03-02)

Five most similar CRAN packages

• grumpy 'Read 'NumPy' '.npy' and '.npz' Files' (v0.1.1, published 2026-05-19)
• reticulate 'Interface to 'Python'' (v1.46.0, published 2026-04-09)
• RIA 'Radiomics Image Analysis Toolbox for Medial Images' (v1.7.2, published 2024-01-08)
• quickr 'Compiler for R' (v0.3.0, published 2026-04-18)
• pacs 'Supplementary Tools for R Packages Developers' (v0.6.0, published 2024-09-27)

---

Matches are generated by the 'pkgmatch' package, based on inverse-term frequencies; see the main function documentation for details.

[ropensci-review-bot]

Checks for grumpy (v0.1.1.9000)

git hash: 4a2dfad3

• ✔️ Package is already on CRAN.
• ✔️ has a 'contributing' file.
• ✔️ uses 'roxygen2'.
• ✔️ 'DESCRIPTION' has a URL field.
• ✔️ 'DESCRIPTION' has a BugReports field.
• ✔️ Package has at least one HTML vignette
• ✔️ All functions have examples.
• ✔️ Repository has a website
• ✖️ Package fails continuous integration checks.
• ✔️ Package coverage is 91.7%.
• ✔️ R CMD check found no errors.
• ✔️ R CMD check found no warnings.
• 👀 Some goodpractice linters failed.

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

(Checks marked with 👀 may be optionally addressed.)

Package License: MIT + file LICENSE

---

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	58
internal	grumpy	8
internal	utils	1
imports	jsonlite	1
suggests	quarto	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

list (6), vapply (5), file (4), readBin (4), character (3), lapply (3), length (3), seq_len (3), as.integer (2), for (2), if (2), integer (2), prod (2), return (2), sub (2), sum (2), vector (2), c (1), cumsum (1), rep (1), rep_len (1), rev (1), seq (1), seq_along (1), startsWith (1), unz (1)

grumpy

parse_npy_datatype (2), parse_npy_descr (2), convert_bytes_to_array (1), convert_py_dict_to_json (1), read_npy (1), read_npz (1)

jsonlite

fromJSON (1)

utils

unzip (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 C (56% in 4 files), Python (8% in 1 files) and R (35% in 3 files)
• 2 authors
• 3 vignettes
• no internal data file
• 1 imported package
• 4 exported functions (median 30 lines of code)
• 2 non-exported functions in R (median 7 lines of code)
• 11 Python functions (median 34 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	3	42.4
files_src	4	92.5
files_inst	1	72.7
files_vignettes	0	0.0	TRUE
files_tests	3	83.3
loc_R	176	57.3
loc_src	280	31.3
loc_inst	41	30.0
loc_tests	309	71.1
num_vignettes	3	94.6
n_fns_r	6	55.3
n_fns_r_exported	4	54.5
n_fns_r_not_exported	2	59.8
n_fns_src	11	84.7
n_fns_per_file_r	3	72.0
n_fns_per_file_src	3	83.9
num_params_per_fn	1	40.4
loc_per_fn_r	18	73.2
loc_per_fn_r_exp	30	76.0
loc_per_fn_r_not_exp	8	70.1
loc_per_fn_src	34	98.2	TRUE
doclines_per_fn_exp	16	45.6
doclines_per_fn_not_exp	21	97.8	TRUE
fn_call_network_size	17	69.3

---

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)

---

3b. goodpractice results

Test coverage with covr

Package coverage: 91.67

Cyclocomplexity with cyclocomp

No functions have cyclocomplexity >= 15

Static code analyses with lintr

lintr found the following 5 potential issues:

message	number of times
Avoid undesirable operator :::.	1
Lines should not be more than 80 characters.	4

---

Package Versions

package	version
pkgstats	0.2.3.1
pkgcheck	0.1.2.311

---

Editor-in-Chief Instructions:

Processing may not proceed until the items marked with ✖️ have been resolved.

This package has some noteworthy properties, see 'Package Statistics' details above.

[maurolepore]

For the record this, follows the following pre-submission where the editorial board considered this package in scope:

• Pre-submission: grumpy. Read NumPy .npy and .npz files in R. #772

@Bisaloo please see

✖️ Package fails continuous integration checks.

[maurolepore]

@ropensci-review-bot ping editors

[ropensci-review-bot]

["Editors have been notified."]

[maurolepore]

@ropensci-review-bot assign @njtierney as editor

[ropensci-review-bot]

Assigned! @njtierney is now the editor

[njtierney]

@ropensci-review-bot check package

[njtierney]

Editor checks:

• 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,
  • Is the case for the package well made?
  • Is the reference index page clear (grouped by topic if necessary)?
  • Are vignettes readable, sufficiently detailed and not just perfunctory?
• Fit: The package meets criteria for fit and overlap.
• Installation instructions: Are installation instructions clear enough for human users?
• Tests: If the package has some interactivity / HTTP / plot production etc. are the tests using state-of-the-art tooling?
• Contributing information: Is the documentation for contribution clear enough e.g. tokens for tests, playgrounds?
• License: The package has a CRAN or OSI accepted license.
• 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

Thank you for your submission, @Bisaloo!

I've got a couple of minor checks to resolve before I reach out for reviewers - it is all very minor but I think these will help the reviews focus on other aspects.

package checks

Regarding

✖️ Package fails continuous integration checks.

I see now that most CI checks pass, except for a windows machine runner: https://github.com/Bisaloo/grumpy/actions/runs/28171453739/job/83436463224

With the error message appearing to be:

Caused by error in `processx::run()`:
! System command 'quarto.exe' failed
--- failed re-building 'grumpy.qmd'
SUMMARY: processing the following files failed:
  'features.qmd' 'grumpy.qmd'
Error: Error: Vignette re-building failed.
Execution halted
Error: Error in proc$get_built_file() : Build process failed
Calls: <Anonymous> ... build_package -> with_envvar -> force -> <Anonymous>
Execution halted
Error: Process completed with exit code 1.

I'm not really sure what this error is exactly, but given that it passes on all other runners, I think we are OK to proceed with the review, unless this issue looks particularly problematic to you, @Bisaloo?

Documentation

I am not familiar with the .npy/.npz format, so my comments here are coming from a new-user perspective.

Is the case for the package well made?

I think the README should be a bit more comprehensive. Overall, all of my questions about the package were answered once I finished reading the (very nicely written!) documentation on the pkgdown website.

I can appreciate that summarising all the other content of the vignettes into the README might also increase the cost of maintenance of keeping the same detail up to date in multiple locations.

However, I do think there is a compromise, where there is a bit more detail in the README, and then it can link to other vignettes to provide full detail.

Specifically, reading the README, I think it would benefit from stating:

• Reading .npy/.npz files is currently only possible using reticulate, which can have memory issues for large files, and adds a dependency
• grumpy only has one dependency, jsonlite
• grumpy has more control over reading in specific formats, such as 64 bit integers
• grumpy only performs reading, not writing .npy/.npz formats, and then suggest other packages to use to write to interoperable formats, such as zarr/parquet.

You can then link to the appropriate vignettes for more detail here.

I also think other formats you mention, such as a zarr, and the Rarr package, should contain a hyperlink, as they might be of interest to the user. I see that in the design document, you state:

Writing is out of scope. When working across multiple languages, one should prefer high-performance interoperable format (parquet, zarr, etc.).

Perhaps in the README, and other vignettes, you could give the users a little nudge and demonstrate what a script might look like that then writes a format out to parquet/zarr?

---

Happy to discuss anything further from here, thank you again for your submission!