Skip to content

[R-pkg-devel] Replicating CRAN M1mac checks

7 messages · Pepijn de Vries, Simon Urbanek, Ivan Krylov

Original
Pepijn de Vries
# 
Hi all,

My latest submission is failing on CRAN M1mac:

https://www.stats.ox.ac.uk/pub/bdr/M1mac/CopernicusMarine.out

Having thought I fixed the issue, I resubmitted, but it is still failing on M1mac. My suspicion is that the M1mac machine is missing drivers to read the raster file used in the failing vignette. I would like to confirm my hypothesis before resubmitting. Is there a way to replicate the CRAN M1mac checks?

Closest I got was using rhub with macos-arm64, but it shows no problems:
https://github.com/pepijn-devries/CopernicusMarine/actions/runs/22064225101/job/63751799489

Or should I go ahead, avoid running the code in the vignette if drivers are missing and hope that this was the problem (with the risk that it will fail again at CRAN if it?s a different issue)?
Your thoughts are welcome.

Kind regards,

Pepijn
Simon Urbanek
# 
Pepijn,

it passes on the MacBuilder:
https://mac.r-project.org/macbuilder/results/1771269966-62e0321a80f19c03/
so it looks all good to me with the official recipes binaries, but the error is very cryptic so you could probably add some more sane error handling to your code as what it is reporting is distinctly unhelpful to the user.

Cheers,
Simon
Pepijn de Vries
# 
Hi Simon,

Thanks for the checks and the tips. I would like to improve the error-handling, but I'm not sure what is causing it. Without being able to replicate it, it's hard to implement an improvement. It seems that macbuilder is not replicating the error. Any other checks that will resemble the CRAN M1mac checks?

Thanks!

Pepijn

________________________________________
Van:?Simon Urbanek <simon.urbanek at R-project.org>
Verzonden:?dinsdag 17 februari 2026 04:17
Aan:?Pepijn de Vries <pepijn.devries at outlook.com>
CC:?R-package-devel <r-package-devel at r-project.org>
Onderwerp:?Re: [R-pkg-devel] Replicating CRAN M1mac checks
?
Pepijn,

it passes on the MacBuilder:
https://mac.r-project.org/macbuilder/results/1771269966-62e0321a80f19c03/
so it looks all good to me with the official recipes binaries, but the error is very cryptic so you could probably add some more sane error handling to your code as what it is reporting is distinctly unhelpful to the user.

Cheers,
Simon
Ivan Krylov
# 
? Mon, 16 Feb 2026 13:59:35 +0000
Pepijn de Vries <pepijn.devries at outlook.com> ?????:
Try compiling gdal-3.12.2 yourself with some drivers disabled, then
installing 'sf' with that gdal, then checking your package.

I've tried installing gdal with

cmake ... -DCMAKE_BUILD_TYPE=Release \
 -DCMAKE_INSTALL_PREFIX=$HOME/gdal-3.12.2/install \
 -DGDAL_BUILD_OPTIONAL_DRIVERS:BOOL=OFF

and then sf with

LD_LIBRARY_PATH=$HOME/gdal-3.12.2/install/lib \
 R CMD INSTALL sf_1.0-24.tar.gz \
 --configure-args=--with-gdal-config=$HOME/gdal-3.12.2/install/bin/gdal-config

and then the following check

LD_LIBRARY_PATH=$HOME/gdal-3.12.2/install/lib \
 R CMD check CopernicusMarine_0.4.0.tar.gz

fails with similar but different output:

Quitting from translate.Rmd:70-73 [download-translation]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<error/rlang_error>
Error:
! file not found
---
Backtrace:
    ?
 1. ??base::do.call(cms_download_subset, translated)
 2. ??CopernicusMarine (local) `<fn>`(...)
 3.   ??CopernicusMarine:::.get_stars_proxy(...)
 4.     ??CopernicusMarine:::.muffle_403(...)
 5.     ? ??base::withCallingHandlers(...)
 6.     ??stars::read_mdim(vsi, proxy = TRUE, variable = variable)
 7.       ??sf::gdal_read_mdim(...)
 8.         ??sf:::CPL_read_mdim(...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Simon Urbanek
# 
Pepijn,

I don't see any error handling in your code whatsoever so I would assume this is easily triggered by network issues, e.g if you don't get the file back or it's not what you expect. Remote calls are always tricky, because you can't guarantee they will work, so you should always guard against failure. You seem to be intentionally ignoring 403 so I wonder if that's what will trigger it.

Cheers,
Simon
Pepijn de Vries
# 
Hi all,

@Elias: I'm pretty sure they tested the new submission.
@Ivan: thanks for the hint, I'll see if I'm able to build sf with a different gdal version. But the file not being found is a more informative error.
@Simon: I'm intentionally ignoring the 403 warnings, because GDAL is trying directory listing requests, that are not allowed by the server (responding with 403). It does not need the directory listing, and will proceed without them, so the function should still work. But you are right that it cannot be guaranteed that online services are available. The problem is that the online requests are made by GDAL (via the sf package) and cannot be caught that easily. I will have to work what the sf-package is handling.

I'll give it some thought... Thanks!

Cheers,

Pepijn

________________________________________
Van:?Simon Urbanek <simon.urbanek at R-project.org>
Verzonden:?dinsdag 17 februari 2026 11:33
Aan:?Pepijn de Vries <pepijn.devries at outlook.com>
CC:?R-package-devel <r-package-devel at r-project.org>
Onderwerp:?Re: [R-pkg-devel] Replicating CRAN M1mac checks
?
Pepijn,

I don't see any error handling in your code whatsoever so I would assume this is easily triggered by network issues, e.g if you don't get the file back or it's not what you expect. Remote calls are always tricky, because you can't guarantee they will work, so you should always guard against failure. You seem to be intentionally ignoring 403 so I wonder if that's what will trigger it.

Cheers,
Simon
Simon Urbanek
# 
Pepijn,

I understand that the actual fetching code is in stars, but given that you know it can fail, you can recover gracefully instead of failing with an uninformative message (or provide a helpful error and catch it in the vignette). In the end it is your responsibility since you are providing the API, the user shouldn't' need to know anything about the intricacies of what happens under the hood in other packages.

Cheers,
Simon