chronosphere-info / r_client

R client for the chronosphere
https://chronosphere.info/r_client/
GNU General Public License v3.0
6 stars 4 forks source link

Reverse dependency check failure with raster 3.6.0 #9

Closed rsbivand closed 1 year ago

rsbivand commented 2 years ago

Careful checking of your package as raster replaces rgdal and rgeos is advised. With raster development version 3.6.0 (and PROJ 9.1.0, GDAL 3.5.2), I get: 00check.log

rsbivand commented 1 year ago

This package and icosa depend on (depends, imports or suggests) raster and one or more of the retiring packages rgdal, rgeos or maptools (https://r-spatial.org/r/2022/04/12/evolution.html). Since raster 3.6.3, all use of external FOSS library functionality has been transferred to terra, making the retiring packages very likely redundant. It would help greatly if you could remove dependencies on the retiring packages as soon as possible.

adamkocsis commented 1 year ago

Thanks for the note! Yes, I am aware of the issue - this package is getting restructured (i.e. broken up), which takes a bit more time than anticipated. I will try to finish this ASAP.

rsbivand commented 1 year ago

These are recent check log from running under _SP_EVOLUTION_STATUS_=2 without retiring r-spatial packages (suggested in these packages) on the library path: 00check.log 00check.log Both involve the unconditional use of retiring suggested packages - could you condition on the availability of them as a first correction step, and move to replace use with other packages if the xamples/vignettes are needed?

adamkocsis commented 1 year ago

I see, thanks! The issue should already be resolved for icosa. The dependent classes and methods in chronosphere were already adapted to work with sf and terra and were migrated to the alpha version of via. Now I am refactoring chronosphere and its remote(s) to work with the new dependency.

I can do a temporary update of chronosphere, but that would mean some disruption in the functionality, which I would rather avoid - unless the issue is really-really pressing. If not, the new version should be on CRAN before May.

rsbivand commented 1 year ago

By May will be fine, thanks for your cooperation!

rsbivand commented 1 year ago

Expect package to fail CRAN CMD check with _R_CHECK_SUGGESTS_ONLY_=true when sp 2.0-0 is published very soon, if sf is not added to Suggests:; currently fails if sf not explicitly suggested at:

> edge <- mapedge()
Warning in CRS("+proj=longlat") : sf required for evolution_status==2L
> molledge <- spTransform(edge, CRS("+proj=moll"))
Warning in CRS("+proj=moll") : sf required for evolution_status==2L
Error in spTransform(edge, CRS("+proj=moll")) : 
  sf required for evolution_status==2L
Calls: spTransform -> spTransform
adamkocsis commented 1 year ago

Thanks for the repeated reminder! I was forced to prioritize other projects and this had to be pushed back further.

The new version of chronosphere was submitted to the CRAN yesterday, and with that all references to the old spatial dependencies are resolved - and this issue should be finally resolved for good. I will close the thread.

rsbivand commented 1 year ago

Confirmed that 0.5.0 passes CMD check without retiring packages on the library path! Thanks!