Disable scipy error test

[t-kalinowski]

This removes a failing test which CRAN reported as failing with reticulate release 1.36.
The failing test is:

expect_error(sp$bsr_matrix(list(3, 4)))

Looking a little closer, it looks like this was never supposed to error.
For example, the equivalent code succeeds in Python, and it should've in R as well.

import scipy.sparse as sp
x = sp.bsr_matrix([3, 4])
print(repr(x))

<1x2 sparse matrix of type '<class 'numpy.longlong'>'
	with 2 stored elements (blocksize = 1x1) in Block Sparse Row format>

This code both with the current release of scipy, v1.13.0, and as well as v1.3.3, the released Nov 2019.

This did indeed error with reticulate 1.35 and older versions, but the error was unrelated, and incorrect. Specifically, it would signal an R error with traceback:

<error/rlang_error>
Error in `py_to_r.default()`:
! Object to convert is not a Python object
---
Backtrace:
    ▆
 1. └─sp$bsr_matrix(list(3, 4))
 2.   ├─reticulate::py_to_r(result)
 3.   └─reticulate:::py_to_r.scipy.sparse.base.spmatrix(result)
 4.     ├─reticulate::py_to_r(x$tocsc())
 5.     └─reticulate:::py_to_r.default(x$tocsc())

I.e., the call to sp$bsr_matrix() would succeed, but then x$tocsc() would convert to an R object automatically which did not need additional py_to_r() processing. With reticulate 1.36, reticulate::py_to_r() now reflects non-Python objects instead of signaling an error.

rstudio/reticulate#1577

[eddelbuettel]

Thanks for the note. The sparse matrix code (and its tests) are all a few years old, it is possible that something got dusty. It looks like we switched to using reticulate here in Feb 2020, the code itself got added in 2017. And it looks like we already 'parked' the two preceding lines so no objections.

How soon to you need this at CRAN? We aim to have a 'roughly less than monthly' cadence and just had a release.

[t-kalinowski]

How soon to you need this at CRAN?

I replied to CRAN with an explanation and a link to this PR, let's see what they say.

I'm hoping to get reticulate on CRAN as soon as possible, so we can then release updated versions of keras and tensorflow.

[eddelbuettel]

I am in reasonably good standing with them so if you say this has been merged and will be fixed in the next upload of RcppArmadillo we may be good (enough).

Could I ask you to put a ChangeLog entry in? Usual format (date, name, email; all with two spaces, then a tab and * with the file and a one or two liner surrounded by empty lines. C-x 4 a for those of us with that editor ... Thanks!

[t-kalinowski]

Kurt asks:

If its tests start showing an ERROR it should get updated within 2 weeks.
Perhaps you can discuss with Dirk whether he could provide an exceptional emergency update within this time frame?

[eddelbuettel]

Well it is not 'discussing with me', it is discussing with them :) to relax their counting penalising me if I attempt a seventh upload in six months. I could play hardnosed and say no counter reset, no bug fix. But I tend to be that adamant only for Rcpp, really. So I guess 'yes we can or could'. Do you want to go to CRAN before you do?

[t-kalinowski]

Thanks! I'm still waiting to hear back from CRAN on exact requirements (i.e., if this will hold up reticulate), but either way, an updated RcppArmadillo on CRAN would be very appreciated!

[t-kalinowski]

Reticulate v1.36 is now on CRAN, with RcppArmadillo tests now failing on CRAN.

[eddelbuettel]

Yep, saw the upload via CRANberries.

[eddelbuettel]

Shipped an updated RcppArmadillo to CRAN so 🤞 hopefully in a few hours it will all be fine.

[eddelbuettel]

@t-kalinowski : Just got the anticipated 'Thanks, on its way to CRAN.' so we should be set soon.

[t-kalinowski]

Thank you for the quick turnaround!

[eddelbuettel]

My pleasure! The main 'cost' is just in the emailing back and forth as with 1100+ rev.deps invariably a false positive pops up here or there...