Re: [R-pkg-devel] Submitting breaking changes to CRAN

[Duncan Murdoch]

One part of your first message that I don't understand is the reluctance 
of downstream package writers to update to the spatstat. versions.


You said "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."


Why wouldn't those new versions work already?  I'm guessing there is 
some incompatibility between the new spatstat. packages and the old 
spatstat 1.65 from before the split.  Can you describe what it is? 
Maybe there's a way to make the new packages compatible with the old 
one, so there would be no excuse for the downstream packages not to 
update right away.


Duncan Murdoch


On 11/03/2021 7:39 p.m., Ege Rubak wrote:

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

[R-pkg-devel] Checking compiled code ... WARNING

[Elysée Aristide]

Dear all,

I checked (as cran) my package PartialNetwork
 and I got this warning.

* checking compiled code ... WARNING
File ‘PartialNetwork/libs/PartialNetwork.so’:
Found ‘__assert_fail’, possibly from ‘assert’ (C)
Object: ‘RcppExports.o’

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor use Fortran I/O
nor system RNGs.

I am wondering if this is because I used Rprintf (line 147 in this file
)
and prgcpp.increment() (line 184 in this file

) to show the progression of the program from C++ functions.
If this is the source of this  warning, how can I print from C++ functions
in the console? I thought that Rprintf and prgcpp.increment() are the best
ways to do it. I know that using cout and endl causes this warning but I do
not use them.

Thank you!

*-*

*Aristide Elysée HOUNDETOUNGAN*
*Ph.D. Candidate in Economics at Université Laval*
*Personal website : *www.ahoundetoungan.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] Checking compiled code ... WARNING

[Iñaki Ucar]

Now with the list in CC, apologies.

On Fri, 12 Mar 2021 at 21:12, Elysée Aristide  wrote:
>
> Dear all,
>
> I checked (as cran) my package PartialNetwork
>  and I got this warning.
>
> * checking compiled code ... WARNING
> File ‘PartialNetwork/libs/PartialNetwork.so’:
> Found ‘__assert_fail’, possibly from ‘assert’ (C)
> Object: ‘RcppExports.o’

I cannot reproduce this. So this is most probably a local artifact
product of some local flag. E.g., _GLIBCXX_ASSERTIONS, which is set by
default in Fedora, is known to cause this kind of warning. Therefore
it is probably safe to send your package to CRAN.

To be sure, my suggestion is to use the rhub service to check your
package [1]. Settings there will probably be quite similar to CRAN.
And winbuilder, of course [2].

On the other hand, I see that your package takes *forever* to check.
That *is* a problem for a CRAN submission. You should try to
drastically reduce checking time, possibly skipping non-essential
tests and examples on CRAN.

[1] https://cran.r-project.org/web/packages/rhub/index.html
[2] https://win-builder.r-project.org/

-- 
Iñaki Úcar

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel