terra usage is not robust to missing/invalid GDAL/PROJ installation

[brownag]

Make tests more robust to potentially missing proj.db. May be related to use of Windows binaries from the RSPM as opposed to CRAN?

e.g. tests occasionally generate errors and warnings on Windows: https://github.com/ncss-tech/soilDB/actions/runs/13509235493/job/37745790683

PROJ: proj_create_from_database: Cannot find proj.db (GDAL error 1)

and

Error: Error: [rast] empty srs

[dylanbeaudette]

Did some research on testing for this condition, and the best that I could find involves looking for "proj.db" in sf/proj, relative to where R packages are installed.

Seems that most people experiencing this problem (in R vs. other software) has to do with incorrectly built packages outside of CRAN.

Unless anyone has a better idea, I'm going to rely on the following for these kind of requests.

skip_if_offline()
skip_on_cran()
skip_if_not_installed("sf")
skip_if_not_installed("terra")

[brownag]

So, those skip commands are not adequate to catch this condition, they were already present and the error still (intermittently) happened. sf/terra are installed but the PROJ database cannot be found due to not being configured properly This type of thing happens when using the RStudio package manager, possibly also with sources like R-Universe or systems with multiple PROJ installs.

[brownag]

As far as suggestions, considering that terra throws the error, the only way to handle it would be to try/tryCatch() around the rast() call, and returning try-error or other sentinel, then skipping remaining tests.

I am not very concerned about this, it is only of minor concern to the CI, but to "fix" we essentially need to treat certain PROJ-based operations similarly to how we handle web requests for error handling

[dylanbeaudette]

Thanks for the suggestions. I realize that this is a special case, as the GDAL/proj stack has always been a difficult one to track across all platforms and build environments. Wrapping all calls to e.g. rast() is a solution, but how far do we take this kind of safe handling? If the CI continued to have issues with other packages, Would it be a good use of time to wrap all functions calling external libraries or (outside of R) dependencies. I'm not so sure.

Would it be sufficient to wrap these functions in the test with try(), so as not to through an error that causes the test to fail in the CI?

[brownag]

This has been done already in many tests (skip on try error, or NULL, or similar), and yes it would be sufficient to wrap the functions in the tests. Also, IMO, yes, it is a good use of time to add error handling, informative messages, skipping when dependencies for non-critical functionality are missing.

[brownag]

This is still causing problems this week. All of the functions referenced in this issue are still causing problems.

After a bit of thought, I am going to create a new internal helper function that needs to be used to skip any tests or examples that rely on a fully-functioning terra installation.

The function will return a logical value: TRUE if we can initialize a SpatRaster and SpatVector object with a CRS properly, FALSE on warning or error.

Something like:

.terra_can_initialize_spatial_object <- function() {
  requireNamespace("terra", quietly = TRUE) && tryCatch({
    terra::rast(matrix(0), crs = "OGC:CRS84")
    terra::vect("POINT (0 0)", crs = "OGC:CRS84")
    # warning("smoke test")
    TRUE
  }, warning = FALSE, error = FALSE)
}

This can replace basically all usage of requireNamespace("terra") with the benefit of being a more complete check of whether the required functionality e.g. proj.db is there