search

dankelley / oce

R package for oceanographic processing
http://dankelley.github.io/oce/
GNU General Public License v3.0
143 stars 42 forks source link

prepare for CRAN submission #2068

Closed dankelley closed 1 year ago

dankelley commented 1 year ago

We need a submission within the next month or so, to address the requirement to reduce dependence on the rgeos and raster packages.

@richardsc suggested he will look into issues #2069 and #2070. Perhaps solutions to these will be ready soon enough for say a week "cooling off" period prior to submission.

dankelley commented 1 year ago

Hi @richardsc and @clayton33.

I'm thinking of bumping the version number, using 1.8.0 instead of 1.7.11, because we the new ad2cp scheme, which would break old user code. (The old scheme was ill-conceived and even if some users had code for it, they will find the new version a lot easier to work with). Another user-visible change is the echosounder colour scheme. Changing the second number is a signal to users that oce has not just had bugs fixed and new things added, but also that some things that previously existed have been changed.

Do you two agree with using 1.8.0 as the version?

oce 1.7.11

clayton33 commented 1 year ago

Making the version 1.8.0 sounds good to me.

richardsc commented 1 year ago

+1 from me

dankelley commented 1 year ago

Thanks. I'm renaming it 1.8.0, and I've restarted the checklist for submission (first comment in this issue). Since I had a contact from a CRAN member, I am inclined to submit on Saturday morning, unless somebody objects.

dankelley commented 1 year ago

With "main" commit 3c7e4e80db5e2f7651a6b37dbd592110a18daed3, the initial checklist is done except for the submission part.

I plan a release on Saturday morning, unless something comes up. A release seems to be warranted after any CRAN suggestion to submit a new version.

As a reminder, the suggestion to submit was based on remote-build errors. But those have gone away, evidently being due to problems on the testing machines. I still see one error at https://cran.r-project.org/web/checks/check_results_oce.html but that is for the mac-arm machine, and the error is

ld: library not found for -lquadmath

which has nothing to do with oce. (It seems that the machine's libraries are not set up right.)

richardsc commented 1 year ago 
ld: library not found for -lquadmath

I saw this too, but couldn't reproduce on my mac-arm.

I still have a hope to do some testing re: #2069 and #2070. But if you really want to release this (long weekend) I don't have a strong reason to suspect there are major issues.

dankelley commented 1 year ago

@richardsc --We can certainly wait for more tests. Do you have an idea on a possible time-frame for them? To get parallel processing, it might be smart to report problems for either #2069 or #2070 first, so I can fix the code when you do tests on the other. I don't think we need to fix any and all problems in either category to make a release, but we will need stable code (that passes the whole checklist given above) to avoid hurting users with new code that is faulty.

PS. the checklist takes about half a day (of non-continuous work) if I ignore the rhub tests. Those rhub tests take something like 6 hours of elapsed time, but they are not worth much, given how often they have errors that are unrelated to oce. Oh, in addition to the checklist, I also check (in tests_private) a bunch of other files I have (20 RDI files, 1 sontek file, 834 cnv files, 516 ODF files, etc). But that only takes maybe half an hour to process.

dankelley commented 1 year ago

My plan is to submit oce to CRAN today or tomorrow. To that end I will now uncheck everything in the checklist, and start over on that.

dankelley commented 1 year ago

I just submitted (see below). Note that submissions usually have some problems, and I'll address them as required.

[This was generated from [CRAN.R-project.org/submit.html](http://cran.r-project.org/submit.html)] The following package was uploaded to CRAN: =========================================== Package Information: Package: oce Version: 1.8-0 Title: Analysis of Oceanographic Data Author(s): Dan Kelley [aut, cre] (), Clark Richards [aut] (), Chantelle Layton [ctb] (, curl() coauthor), British Geological Survey [ctb, cph] (magnetic-field subroutine) Maintainer: Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)> Depends: R (>= 2.15), gsw, methods, utils Suggests: automap, DBI, foreign, interp, knitr, lubridate, ncdf4, ocedata, rmarkdown, RSQLite, R.utils, sf, sp, terra, testthat (>= 3.0.0), tiff, XML Description: Supports the analysis of Oceanographic data, including 'ADCP' measurements, measurements made with 'argo' floats, 'CTD' measurements, sectional data, sea-level time series, coastline and topographic data, etc. Provides specialized functions for calculating seawater properties such as potential temperature in either the 'UNESCO' or 'TEOS-10' equation of state. Produces graphical displays that conform to the conventions of the Oceanographic literature. This package is discussed extensively by Kelley (2018) "Oceanographic Analysis with R" . License: GPL (>= 2) Imports: Rcpp LinkingTo: Rcpp The maintainer confirms that he or she has read and agrees to the CRAN policies. Submitter's comment: # Submission of oce 1.8-0 As in previous CRAN submissions, we request an exception to the 10-minute rule, on account of the package size (300+ functions, covering 60k lines of R, 6k lines of C/C++ and 1k line of Fortran). A key reason for the submission is a request to remove dependence on rgeos and raster packages, which are being superseded by newer packages. The NEWS.md file lists over a dozen additional changes. Of these, two have user-visible changes. First, plot() for echosounder-class objects now uses the viridis colour-scheme by default (it was jet, previously). Second, and more significantly, AD2CP objects now have a layout that matches other oce objects, simplifying the analysis of such data. ## Local Tests R 4.3.0 on MacOS-14 (beta) revealed no ERRORs, no WARNINGs, and 2 NOTEs. One of the NOTEs is the standard naming of the author, and the other is an indication of sub-directories over 1MB in size, now as has been the case going back several years, for this large package. ## Remote Windows Checks Using ```R devtools:::build_win_release() devtools:::build_win_oldrelease() devtools:::build_win_devel() ``` identified no errors. ## Other checks The following checks passed without difficulty, except that some of the RHUB checks failed for reasons unrelated to the package (owing, it seems, to difficulties in the setup of the testing machines). ``` devtools::spell_check() urlchecker::url_check() devtools::check_win_release() devtools::check_win_devel() devtools::check_win_oldrelease() rhub::check_for_cran(email="[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)", show_status=FALSE) revdepcheck::revdep_reset() revdepcheck::revdep_check(num_workers=4) ``` ================================================= Original content of DESCRIPTION file: Package: oce Title: Analysis of Oceanographic Data Version: 1.8-0 Authors@R: c( person(given="Dan", family="Kelley", email="[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)", role=c("aut", "cre"), comment=c(ORCID="https://orcid.org/0000-0001-7808-5911")), person(given="Clark", family="Richards", email="[clark.richards@gmail.com](mailto:clark.richards@gmail.com)", role=c("aut"), comment=c(ORCID="https://orcid.org/0000-0002-7833-206X")), person(given="Chantelle", family="Layton", email="[chantelle.layton@dal.ca](mailto:chantelle.layton@dal.ca)", role=c("ctb"), comment=c(ORCID="https://orcid.org/0000-0002-3199-5763", "curl() coauthor")), person(given="British Geological Survey", role=c("ctb","cph"), comment="magnetic-field subroutine")) Maintainer: Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)> Depends: R (>= 2.15), gsw, methods, utils Suggests: automap, DBI, foreign, interp, knitr, lubridate, ncdf4, ocedata, rmarkdown, RSQLite, R.utils, sf, sp, terra, testthat (>= 3.0.0), tiff, XML BugReports: https://github.com/dankelley/oce/issues Description: Supports the analysis of Oceanographic data, including 'ADCP' measurements, measurements made with 'argo' floats, 'CTD' measurements, sectional data, sea-level time series, coastline and topographic data, etc. Provides specialized functions for calculating seawater properties such as potential temperature in either the 'UNESCO' or 'TEOS-10' equation of state. Produces graphical displays that conform to the conventions of the Oceanographic literature. This package is discussed extensively by Kelley (2018) "Oceanographic Analysis with R" . License: GPL (>= 2) Encoding: UTF-8 URL: https://dankelley.github.io/oce/ LazyData: false Roxygen: list(markdown = TRUE) RoxygenNote: 7.2.3 BuildVignettes: true VignetteBuilder: knitr NeedsCompilation: yes LinkingTo: Rcpp Imports: Rcpp Packaged: 2023-04-25 09:29:14 UTC; kelley Config/testthat/edition: 3 Author: Dan Kelley [aut, cre] (), Clark Richards [aut] (), Chantelle Layton [ctb] (, curl() coauthor), British Geological Survey [ctb, cph] (magnetic-field subroutine)
dankelley commented 1 year ago

First hiccup. (One must look through all the linked material; the "Status: OK" you see here is not enough.)

Dear maintainer, package oce_1.8-0.tar.gz does not pass the incoming checks automatically, please see the following pre-tests: Windows: Status: OK Debian: Status: OK Last released version's CRAN status: OK: 5, NOTE: 8 See: CRAN Web: Please fix all problems and resubmit a fixed version via the webform. If you are not sure how to fix the problems shown, please ask for help on the R-package-devel mailing list: If you are fairly certain the rejection is a false positive, please reply-all to this message and explain. More details are given in the directory: The files will be removed after roughly 7 days. *** Strong rev. depends ***: argoFloats callsync dendroTools locaR morphomap seacarb skyscapeR soundecology SWMPr vprr Best regards, CRAN teams' auto-check service Flavor: r-devel-windows-x86_64 Check: CRAN incoming feasibility, Result: NA Maintainer: 'Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)>' Flavor: r-devel-windows-x86_64 Check: Overall checktime, Result: NOTE Overall checktime 11 min > 10 min Flavor: r-devel-linux-x86_64-debian-gcc Check: CRAN incoming feasibility, Result: Note_to_CRAN_maintainers Maintainer: 'Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)>'
dankelley commented 1 year ago

I've followed all the links (see previous comment) and see no problems. I do see

Flavor: r-devel-windows-x86_64
Check: CRAN incoming feasibility, Result: NA
 Maintainer: 'Dan Kelley <[Dan.Kelley@Dal.Ca](mailto:Dan.Kelley@Dal.Ca)>'

and also that case has an elapsed time exceeding 10 minutes. So I think that is the problem. (This has been the case for many years. And I talked about it in the submission notes.)

dankelley commented 1 year ago

Oh, crossing emails. As I clicked to send an email to CRAN asking for an over-ride on the 10-minute limit, I got an email from a CRAN member that oce had been put forward to the next step in the process.

dankelley commented 1 year ago

It's on the way.

Dear maintainer, thanks, package oce_1.8-0.tar.gz is on its way to CRAN. Best regards, CRAN teams' auto-check service Package check result: OK No changes to worse in reverse depends.
dankelley commented 1 year ago

I'll track the appearance of versions on a CRAN mirror (https://cran.r-project.org/web/packages/oce/index.html), and update the list below a few times per day. After a few boxes have been ticked, I'll close the issue (but keep checking every few days).

dankelley commented 1 year ago

I'm doing to close this now. The macOS x86_64 binaries are a bit slow in coming. I think I've seen that pattern before. The others all worked fine.

Unfortunately, there is an ugly error at the test page (#2080) because a warning about kriging was turned into an error. That warning has nothing to do with oce, though; it's about how a package oce calls is interacting with the OS. I don't want to make a release to resolve that and indeed would not be permitted to do so by CRAN, but I have wrapped that example code in dontrun in the "develop" branch, so the problem won't appear in future releases.