Re: [R-pkg-devel] Submitting breaking changes to CRAN
Dear Duncan, Thanks for taking the time to read my message and for the constructive idea. You are right that it is a bit late for us to do this now. Given that spatstat (<=1.65) exports >2,500 objects which are now spread across sub-packages we would obviously have to make a script to help us reexport the functions and make documentation containing links to the real man page. This might be doable, but one big downside is that we then don't use this occasion to move package dependencies from spatstat to the relevant spatstat.. If the packages don't fail I'm afraid that a lot of maintainers wont change anything, and their package will depend on the entire ensemble of spatstat packages rather than just the relevant sub-package(s). For our usual end users this would also mean that when they open the help file of given function after attaching spatstat it will just contain a huge list of links to the real help file they are looking for which is a nuisance. Unless we get other really good suggestions we will wait a bit more on a reply from CRAN (we sent a gentle reminder a week ago) and hopefully learn what we should do differently to get the last bit in place. Best regards, Ege On Thu, 2021-03-11 at 14:56 -0500, Duncan Murdoch wrote: > It may be too late to do this now, but you could use the approach > that > devtools used when it was broken up: The main package imports > functions > from the new spatstat. packages and exports them. This way it > could > be done with no breaking changes. Reverse dependencies could change > to > depend on spatstat. at their leisure. > > Duncan Murdoch > > On 11/03/2021 10:18 a.m., Ege Rubak wrote: > > Dear all, > > > > I'm seeking advice on how to submit a new package version with > > breaking > > changes to CRAN. I will try to make this short: > > > > 1. spatstat (<= 1.65) had grow to be very large with extensive > > examples, tests, and documentation. > > 2. CRAN asked us to reduce package size and check time. > > 3. We reorganized the package into a new umbrella package spatstat > > 2.0 > > which Depends/Imports several subpackages named spatstat.. > > 4. All subpackages are now on CRAN. > > 5. We submitted spatstat 2.0-1 which breaks 79 reverse dependencies > > because they e.g. call functions that have been moved from spatstat > > to > > spatstat.. > > 6. All maintainers have been warned over a period of months and > > offered > > detailed help to adjust their package. Many have reported back that > > they have a new version ready that will work with spatstat (>=2.0) > > and > > are waiting to submit until it is on CRAN. > > 7. We received notification on 23 Feburary that "package > > spatstat_2.0- > > 1.tar.gz has been auto-processed. The auto-check found problems > > when > > checking the first order strong reverse dependencies. > > Please reply-all and explain: Is this expected or do you need to > > fix > > anything in your package? If expected, have all maintainers of > > affected > > packages been informed well in advance? Are there false positives > > in > > our results?" > > 8. We replied to all on the same day, 23 Feb, that this was > > expected > > and maintainers had been informed. Since then we have no news. > > > > Any advice on how to cross the finish line and get spatstat 2.0-1 > > on > > CRAN without putting too big a burden on the CRAN volunteers? > > > > I can only come up with a long shot: > > > > Ask package maintainers to submit their spatstat 2.0 compatible > > package > > to CRAN with an additional line in DESCRIPTION: > > > > Additional_repositories: https://spatstat.r-universe.dev > > > > Since spatstat 2.0-1 is available from this repository they may > > pass > > the incoming checks on CRAN, but my hopes are not too high. > > > > If this was successful the reverse dependencies would be compatible > > with spatstat 2.0 and on CRAN and so spatstat 2.0 would break > > nothing > > and we could resubmit. > > > > Best regards, > > Ege > > > > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD build --resave-data not working
This is a bug in R 4.0.0 - R 4.0.4 affecting packages using LazyData. Two possible workarounds: - Manually run tools::resaveRdaFiles() on your data directory before building the package. - Use a current development version of R (4.0.4-patched >= r80069 or R-devel >= r79573) Best regards, Sebastian Meyer PS: This is a duplicate of a recent discussion on this list, see https://stat.ethz.ch/pipermail/r-package-devel/2021q1/006643.html Am 11.03.21 um 21:57 schrieb Jonathan Callahan: > I am building a package using R 4.0.4 on OS X 10.15.7. > > In a terminal I type: > > R CMD build --resave-data AirSensor > > Then, I check with: > > R CMD check --as-cran AirSensor_1.0.8.tar.gz > > Everything is fine until I see: > > > * checking data for ASCII and uncompressed saves ... WARNING > > > > Note: significantly better compression could be obtained > > by using R CMD build --resave-data > > old_size new_size compress > > example_pas.rda 1.6Mb1.1Mb xz > > example_pas_raw.rda 114Kb 86Kb xz > > example_pat.rda 965Kb444Kb xz > > example_pat_failure_A.rda527Kb259Kb xz > > example_pat_failure_B.rda411Kb198Kb xz > > example_sensor_scaqmd.rda108Kb 76Kb xz > > I get the same WARNING if I submit to win-builder.R-project.org. > > I've built many packages in the past and am currently stumped as to what > might be happening. > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD build --resave-data not working
Hmm, I may have written too quickly. I find these lines from R CMD build --help confusing: --resave-data=re-save data files as compactly as possible: "no", "best", "gzip" (default) --resave-data same as --resave-data=best The first line suggests that gzip compression is the default. The second suggests that "best" is the default. And are we supposed to use quotation marks or not ... ? In any case, --resave-data=best and --resave-data="best" both seem worth a try. On 3/11/21 3:57 PM, Jonathan Callahan wrote: I am building a package using R 4.0.4 on OS X 10.15.7. In a terminal I type: R CMD build --resave-data AirSensor Then, I check with: R CMD check --as-cran AirSensor_1.0.8.tar.gz Everything is fine until I see: * checking data for ASCII and uncompressed saves ... WARNING Note: significantly better compression could be obtained by using R CMD build --resave-data old_size new_size compress example_pas.rda 1.6Mb1.1Mb xz example_pas_raw.rda 114Kb 86Kb xz example_pat.rda 965Kb444Kb xz example_pat_failure_A.rda527Kb259Kb xz example_pat_failure_B.rda411Kb198Kb xz example_sensor_scaqmd.rda108Kb 76Kb xz I get the same WARNING if I submit to win-builder.R-project.org. I've built many packages in the past and am currently stumped as to what might be happening. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R CMD build --resave-data not working
maybe R CMD build --resave-data=best ... ? On 3/11/21 3:57 PM, Jonathan Callahan wrote: I am building a package using R 4.0.4 on OS X 10.15.7. In a terminal I type: R CMD build --resave-data AirSensor Then, I check with: R CMD check --as-cran AirSensor_1.0.8.tar.gz Everything is fine until I see: * checking data for ASCII and uncompressed saves ... WARNING Note: significantly better compression could be obtained by using R CMD build --resave-data old_size new_size compress example_pas.rda 1.6Mb1.1Mb xz example_pas_raw.rda 114Kb 86Kb xz example_pat.rda 965Kb444Kb xz example_pat_failure_A.rda527Kb259Kb xz example_pat_failure_B.rda411Kb198Kb xz example_sensor_scaqmd.rda108Kb 76Kb xz I get the same WARNING if I submit to win-builder.R-project.org. I've built many packages in the past and am currently stumped as to what might be happening. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R CMD build --resave-data not working
I am building a package using R 4.0.4 on OS X 10.15.7. In a terminal I type: R CMD build --resave-data AirSensor Then, I check with: R CMD check --as-cran AirSensor_1.0.8.tar.gz Everything is fine until I see: * checking data for ASCII and uncompressed saves ... WARNING Note: significantly better compression could be obtained by using R CMD build --resave-data old_size new_size compress example_pas.rda 1.6Mb1.1Mb xz example_pas_raw.rda 114Kb 86Kb xz example_pat.rda 965Kb444Kb xz example_pat_failure_A.rda527Kb259Kb xz example_pat_failure_B.rda411Kb198Kb xz example_sensor_scaqmd.rda108Kb 76Kb xz I get the same WARNING if I submit to win-builder.R-project.org. I've built many packages in the past and am currently stumped as to what might be happening. -- Jonathan Callahan, PhD Mazama Science 206-708-5028 mazamascience.com [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note_to_CRAN_mainteners
As far as I know, this is a harmless note and can be disregarded. (And, can't be eliminated.) (It would be nice if that were clearer in the documentation ... maybe it is and I just haven't checked lately ...) On 3/11/21 2:16 PM, William Andrés Herrera Cáceres wrote: Hi everyone, I am a beginner in developing R packages in CRAN. Now I am trying to submit my package to CRAN but I cannot solve this issue: Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility, Result: NOTE Maintainer: 'William Herrera-C�ceres ' Could someone give me a hand to rid that NOTE? Thank you in advance, William [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Note_to_CRAN_mainteners
Hi everyone, I am a beginner in developing R packages in CRAN. Now I am trying to submit my package to CRAN but I cannot solve this issue: Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-ix86+x86_64 Check: CRAN incoming feasibility, Result: NOTE Maintainer: 'William Herrera-C�ceres ' Could someone give me a hand to rid that NOTE? Thank you in advance, William [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Submitting breaking changes to CRAN
It may be too late to do this now, but you could use the approach that devtools used when it was broken up: The main package imports functions from the new spatstat. packages and exports them. This way it could be done with no breaking changes. Reverse dependencies could change to depend on spatstat. at their leisure. Duncan Murdoch On 11/03/2021 10:18 a.m., Ege Rubak wrote: Dear all, I'm seeking advice on how to submit a new package version with breaking changes to CRAN. I will try to make this short: 1. spatstat (<= 1.65) had grow to be very large with extensive examples, tests, and documentation. 2. CRAN asked us to reduce package size and check time. 3. We reorganized the package into a new umbrella package spatstat 2.0 which Depends/Imports several subpackages named spatstat.. 4. All subpackages are now on CRAN. 5. We submitted spatstat 2.0-1 which breaks 79 reverse dependencies because they e.g. call functions that have been moved from spatstat to spatstat.. 6. All maintainers have been warned over a period of months and offered detailed help to adjust their package. Many have reported back that they have a new version ready that will work with spatstat (>=2.0) and are waiting to submit until it is on CRAN. 7. We received notification on 23 Feburary that "package spatstat_2.0- 1.tar.gz has been auto-processed. The auto-check found problems when checking the first order strong reverse dependencies. Please reply-all and explain: Is this expected or do you need to fix anything in your package? If expected, have all maintainers of affected packages been informed well in advance? Are there false positives in our results?" 8. We replied to all on the same day, 23 Feb, that this was expected and maintainers had been informed. Since then we have no news. Any advice on how to cross the finish line and get spatstat 2.0-1 on CRAN without putting too big a burden on the CRAN volunteers? I can only come up with a long shot: Ask package maintainers to submit their spatstat 2.0 compatible package to CRAN with an additional line in DESCRIPTION: Additional_repositories: https://spatstat.r-universe.dev Since spatstat 2.0-1 is available from this repository they may pass the incoming checks on CRAN, but my hopes are not too high. If this was successful the reverse dependencies would be compatible with spatstat 2.0 and on CRAN and so spatstat 2.0 would break nothing and we could resubmit. Best regards, Ege __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Submitting breaking changes to CRAN
Dear all, I'm seeking advice on how to submit a new package version with breaking changes to CRAN. I will try to make this short: 1. spatstat (<= 1.65) had grow to be very large with extensive examples, tests, and documentation. 2. CRAN asked us to reduce package size and check time. 3. We reorganized the package into a new umbrella package spatstat 2.0 which Depends/Imports several subpackages named spatstat.. 4. All subpackages are now on CRAN. 5. We submitted spatstat 2.0-1 which breaks 79 reverse dependencies because they e.g. call functions that have been moved from spatstat to spatstat.. 6. All maintainers have been warned over a period of months and offered detailed help to adjust their package. Many have reported back that they have a new version ready that will work with spatstat (>=2.0) and are waiting to submit until it is on CRAN. 7. We received notification on 23 Feburary that "package spatstat_2.0- 1.tar.gz has been auto-processed. The auto-check found problems when checking the first order strong reverse dependencies. Please reply-all and explain: Is this expected or do you need to fix anything in your package? If expected, have all maintainers of affected packages been informed well in advance? Are there false positives in our results?" 8. We replied to all on the same day, 23 Feb, that this was expected and maintainers had been informed. Since then we have no news. Any advice on how to cross the finish line and get spatstat 2.0-1 on CRAN without putting too big a burden on the CRAN volunteers? I can only come up with a long shot: Ask package maintainers to submit their spatstat 2.0 compatible package to CRAN with an additional line in DESCRIPTION: Additional_repositories: https://spatstat.r-universe.dev Since spatstat 2.0-1 is available from this repository they may pass the incoming checks on CRAN, but my hopes are not too high. If this was successful the reverse dependencies would be compatible with spatstat 2.0 and on CRAN and so spatstat 2.0 would break nothing and we could resubmit. Best regards, Ege -- Ege Rubak, Associate Professor, Department of Mathematical Sciences, Aalborg University Skjernvej 4A, 9220 Aalborg East, Denmark Phone: (+45)99408861 Mobile: (+45)30230252 Email: ru...@math.aau.dk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
