search

isciences / exactextractr

R package for fast and accurate raster zonal statistics
https://isciences.gitlab.io/exactextractr/
281 stars 26 forks source link

impending CRAN archival #55

Closed jeffreyhanson closed 3 years ago

jeffreyhanson commented 3 years ago

Hi,

Thanks so much for developing the exactextractr package! My colleague @ricschuster (maintainer of the prioritizr R package which has exactextractr listed as an Imports) received an email from CRAN this morning (see below) stating that the exactextractr R package was going to be acrchived next week (2021-05-16). May I ask if you were planning on submitting an updated version to keep exactextractr available on CRAN? Or were you planning on using GitHub for primarily distribution of this package in the future?

Dear maintainers,

This concerns the CRAN packages

GeNetIt exactextractr prioritizr rangeMapper

maintained by one of you:

Daniel Baston dbaston@isciences.com: exactextractr Jeffrey S. Evans jeffrey_evans@tnc.org: GeNetIt Mihai Valcu valcu@orn.mpg.de: rangeMapper Richard Schuster richard.schuster@glel.carleton.ca: prioritizr

We have asked for an update fixing the check problems shown at https://cran.r-project.org/web/checks/check_results_exactextractr.html with no update from the maintainer thus far.

Thus, package exactextractr is now scheduled for archival on 2021-05-16, and archiving this will necessitate also archiving its strong reverse dependencies.

Please negotiate the necessary actions.

The CRAN Team

dbaston commented 3 years ago

I submitted an updated version on April 21. They were having problems running it on Solaris (it works on R-hub Solaris) and did not respond to emails asking for a build log. I will continue trying to work with them on it, but if they are unwilling to provide information I can use to reproduce the error, it's ultimately out of my control.

jeffreyhanson commented 3 years ago

Thanks for getting back to me so quickly. Oh - that must be frustrating. Would it be helpful if @ricschuster and I tried looking into this (e.g. tried asking for the build log, or tried to work out why it's not working)? Looking at the CRAN checks, it seems like another system build/check/thing is also not working (i.e. r-devel-windows-x86_64-gcc10-UCRT -- though I have no idea what this is).

dbaston commented 3 years ago

I've fixed everything reported in the CRAN checks...the clang-UBSAN error with 675f24d8c6cb4d3173e5537109dde13614583baa , added support for the new Windows build chain with 283ca96773443a60077108031b8127853e71fc45 , and fixed the Solaris build wih cec927cbc5c350a6a3160724f03c8e5c84d6c7e2. I set up a Solaris VM and verified that it build and passes all tests there, as well as on the R-hub Solaris builder. It does not work on Solaris if the Oracle compiler is used on Solaris, because Rcpp does not work with the Oracle compiler. BDR tells me the Oracle compiler is not being used, but ... no build log.

jeffreyhanson commented 3 years ago

Oh - I see! Thank you for explaining all that to me, and also for all that work on addressing the CRAN checks. I'm sorry, I was previously mistaken in thinking that the build logs for the CRAN checks on the CRAN version of exactextractr could be of use --- but I now see that is not the case and you need CRAN check logs for the GitHub devel version of exactextractr (but please correct if I am still missing something?). So, I'm not really sure what I can do to help? Do you think it would be worth having another person try emailing BDR asking for the build logs?

jeffreyhanson commented 3 years ago

I just had an idea, but please feel free to ignore if you think it's not worth the effort or wouldn't work:

What do you think about deprecating functionality on Solaris (since I would guess that Solaris users are non-existent)? Intead of compiling the real/working C++ source code on Solaris, could extractextractr be updated to compile C++ dummy functions (e.g. corresponding to those listed in RcppExports.cpp) that just throw an error on Solaris systems? If these dummy functions didn't use any advanced functionality (e.g. CXX17, GEOS, exactextract C++ library) -- and only used standard Rcpp compiler flags -- then they should(?) result in succesful compilation on Solaris systems? Perhaps one way of implementing this could involve updating the configure files to change compiler flags and targets if the package is being compiled on Solaris (e.g. such that only standard Rcpp flags are used, which should work on Solaris, and it does not link to GEOS or the exactextract source library)? What do you think?

jeffreyhanson commented 3 years ago

I just had another idea, this is a bit hacky but would require substantially less effort:

It would appear that not all packages on CRAN are tested under Solaris. Indeed, if we look at the Rsymphony package -- an R package that links to the external SYMPHONY software -- we can see that it is not checked on the Solaris system. This suggests that CRAN has some systems in place for not testing all packages on all build environments. Although I don't know how one could specify that a package should not be checked under Solaris, it would seem that a package is not checked on Solaris if it depends on a package that is not checked on Solaris. For exampe, if we look at the PortfolioOptim package -- which depends on the Rsymphony package -- we can see that it is not checked under Solaris. Therefore -- assuming that reasonable efforts have been made to get a package to pass checks on CRAN's Solaris system (which I would argue is definitely the case here) -- then one mechanism for bypassing these checks is to add the Rsymphony package (or another package that is not checked on Solaris) as a dependency (i.e. listed under Imports).

dbaston commented 3 years ago

Thanks for the ideas, @jeffreyhanson . I've also received advice from a very experienced package author to just have my test code check the OS and skip all tests on Solaris. I have no personal interest in supporting Solaris but am interested in following the spirit of CRAN's requirements. If there is a real issue, I'm happy to investigate and address it. For now, it appears the issue is that the CRAN builder used the wrong compiler by mistake. I just replied to the email your colleague received from CRAN -- we'll see what comes of that in the next day or two.

jeffreyhanson commented 3 years ago

No worries. Ah ok - yeah, that sounds great. Thank you very much for persisting with this. Please let me know if there's anything I can do to help.

dbaston commented 3 years ago

Well, after getting no response from CRAN, I submitted an updated version that has special accommodations for the Oracle compiler they told me they're not using. They seem to have accepted it?

jeffreyhanson commented 3 years ago

Amazing work tracking down the issue and adding in those accomodations for the Oracle compiler! Thank you so much! Fantastic to hear that CRAN's accepted the new version. I'll close this now then - thanks again!