[R-pkg-devel] Matrix 1.7-0 to be released in March with ABI-breaking SuiteSparse update
Dear users and binary repository maintainers,
We are preparing Matrix version 1.7-0 for CRAN submission on March 11, ahead
of the spring release of R version 4.4.0. The only significant change from
Matrix 1.6-5 is an update of the internal SuiteSparse libraries
(5.10.1 -> 7.6.0). Unfortunately, the old and new SuiteSparse versions are
binary incompatible, hence so too will be the old and new Matrix versions.
A corollary is that users and binary repository maintainers switching between
Matrix < 1.7-0 and Matrix >= 1.7-0 must rebuild _from sources_ packages that
link Matrix:
> tools::package_dependencies("Matrix", which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
[4] "GeneralizedWendland" "geostatsp" "irlba"
[7] "lme4""mcmcsae" "OpenMx"
[10] "PRIMME" "PUlasso" "robustlmm"
[13] "spGARCH" "TMB" "bcSeq"
For users, that means doing, e.g.,
install.packages("lme4", type = "source")
but an alternative for Windows and macOS users without the required tools is
oo <- options(repos = "https://cran.r-project.org/;)
install.packages("Matrix")
install.packages("lme4")
options(oo)
where we trust CRAN to provide binaries compatible with the latest Matrix
version (because we notify CRAN upon submission about required rebuilds).
Once other repositories react with rebuilds, they can be used instead of
CRAN.
Our reverse dependency checks (and history, intuition, ...) show that most
problems (caught segfaults in this case) can be traced to a binary incompatible
lme4 and not to one of the other packages linking Matrix. Still, we recommend
rebuilds for all 15 packages.
Maintainers of packages that link Matrix can implement an .onLoad test for
possible binary incompatibility by comparing the value of
if (utils::packageVersion("Matrix") >= "1.6.2")
Matrix::Matrix.Version()[["abi"]]
else numeric_version("0")
at install time and at load time, warning the user if the values differ.
But please do look at the above and not at packageVersion("Matrix") directly,
as the ABI version is incremented less often than the package version.
Mikael {on behalf of citation("Matrix")$author}
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note to repository maintainers about ABI change in Matrix 1.6-2
On 2023-11-10 5:04 pm, Mikael Jagan wrote:
For repositories != CRAN:
Matrix 1.6-2 was released on Nov 8. Due to an ABI change, repositories
maintaining R package binaries should ensure that binaries for the first
order reverse LinkingTo of Matrix are rebuilt under Matrix 1.6-2:
> db <- available.packages(repos = "https://cran.r-project.org/;)
> tools::package_dependencies("Matrix", db = db, which = "LinkingTo", reverse
=
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
[4] "GeneralizedWendland" "geostatsp" "hibayes"
[7] "irlba" "lme4""mcmcsae"
[10] "OpenMx" "PRIMME" "robustlmm"
[13] "spGARCH" "TMB"
The following additional packages were found to have stale SClassExtension
objects cached in their namespaces:
MatrixModels, SeuratObject, softImpute
and so their binaries should be rebuilt also.
Mikael
Typically, ABI changes occur only rarely, when Matrix updates the internal
SuiteSparse libraries and _those_ libraries change _their_ ABI. This case
is an exception: we discovered that certain function prototypes in our
headers were inconsistent with corresponding prototypes in the SuiteSparse
headers, and the "consistent" prototypes were not binary compatible.
It is for this reason (and others) that Matrix has begun versioning its ABI,
as I announced in an earlier thread on R-SIG-Mac:
https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
That (in addition to future, more proactive announcements on mailing lists)
should allow repository maintainers to adapt sooner going forward.
Mikael
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Note to repository maintainers about ABI change in Matrix 1.6-2
For repositories != CRAN:
Matrix 1.6-2 was released on Nov 8. Due to an ABI change, repositories
maintaining R package binaries should ensure that binaries for the first
order reverse LinkingTo of Matrix are rebuilt under Matrix 1.6-2:
> db <- available.packages(repos = "https://cran.r-project.org/;)
> tools::package_dependencies("Matrix", db = db, which = "LinkingTo", reverse =
TRUE)[[1L]]
[1] "ahMLE" "bayesWatch" "cplm"
[4] "GeneralizedWendland" "geostatsp" "hibayes"
[7] "irlba" "lme4""mcmcsae"
[10] "OpenMx" "PRIMME" "robustlmm"
[13] "spGARCH" "TMB"
Typically, ABI changes occur only rarely, when Matrix updates the internal
SuiteSparse libraries and _those_ libraries change _their_ ABI. This case
is an exception: we discovered that certain function prototypes in our
headers were inconsistent with corresponding prototypes in the SuiteSparse
headers, and the "consistent" prototypes were not binary compatible.
It is for this reason (and others) that Matrix has begun versioning its ABI,
as I announced in an earlier thread on R-SIG-Mac:
https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
That (in addition to future, more proactive announcements on mailing lists)
should allow repository maintainers to adapt sooner going forward.
Mikael
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Matrix and Mac OS
A hack that seems to work is (whitespace added for readability):
\newcommand{\Seqn}{
\ifelse{latex}{
\Sexpr[results=rd]{if (getRversion() < "4.2.2") "eqn{#1}" else
"eqn{#2}"}
}{
\ifelse{html}{
\Sexpr[results=rd]{if (getRversion() < "4.2.0") "eqn{#1}"
else "eqn{#2}"}
}{
\Sexpr[results=rd]{"eqn{#2}"}
}
}
}
as amsmath support for PDF output and KaTeX support for HTML output
were introduced in R 4.2.2 and 4.2.0, respectively.
Sadly I really do seem to need 8 escapes:
\Seqn{text{min}(m,n) times n}{min(m,n)-by-n}
Maybe one of the Rd experts here can suggest an improvement ...
Mikael
On 2023-11-01 5:06 am, Martin Maechler wrote:
Uwe Ligges
on Wed, 1 Nov 2023 06:26:23 +0100 writes:
> On 01.11.2023 03:51, Mikael Jagan wrote:
>> Thanks. It seems that we were mistaken in our feeling (IIRC) that it
would
>> be "OK" to implicitly require '--no-manual' on versions of R from 3.5.0
to
>> 4.2.1, not changing our Depends.
>>
>> We will fix this in Matrix 1.6-2, probably by conditionalizing or
otherwise
>> replacing the amsmath commands and probably _not_ by changing to depend
on
>> R >= 4.2.2. Martin may have more to say in "the morning".
I agree (*not* to raise Matrix pkg's R version dependency).
> Note that dependin on R >= 4.2.2 does not work. We need dependencies of
> the form R >= x.y.0. This is also part of the checks.
Yes, indeed.
And as we learned, R >= 4.2.0 would not help for r-oldrel-macos
I (am unhappy but) agree to take the responsibility for our
decision to go ahead and use much nicer LaTeX formula for
matrices etc, in our help pages {thinking that indeed people who'd
install Matrix on an old R version would always be able to read
Matrix manual pages via web search (as it seems to me 95% of
people do nowadays) ... or then have someone in their
organization to figure out how to use a newer amsmath (latex) package if
they really really want the Matrix pdf manual offline}.
Martin
> Reason is that we have only one binary repository for one R-x.y.?
> series. On WIndows, where we check with R-4.2.3, a binary would be
> created and hence R-4.2.[0-1] would not see any valid Matrix binaries.
> So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If
> the latter, ideally with an interim version that works for R >= 4.2.0,
> so that we valid binaries with correct dependency declarations again.
> Best,
> Uwe
>> In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may
>> help
>> to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey revert
its
>> strict version requirement, unless there are clear examples justifying
one.
>>
>> Mikael
>>
>>
>> On 2023-10-31 8:17 pm, Simon Urbanek wrote:
>>> Mikael,
>>>
>>> in that case I think your requirements are wrong - Matrix says R >=
>>> 3.5.0 which is apparently incorrect - from what you say it should be
>>> 4.2.2?. I can certainly update to 4.2.3 if necessary.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>
>>>> On 1/11/2023, at 9:19 AM, Mikael Jagan wrote:
>>>>
>>>> Thanks. We did see those ERRORs, stemming from use (since Matrix
1.6-0)
>>>> of amsmath commands in Rd files. These have been supported since R
>>>> 4.2.2,
>>>> but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R
>>>> 4.2.0.
>>>> My expectation was that those machines would begin running R >= 4.2.2
>>>> well
>>>> before the R 4.4.0 release, but apparently that was wrong.
>>>>
>>>> I am hesitant to complicate our Rd files with conditions on R versions
>>>> only to support PDF output for R < 4.2.2, but maybe we can consider it
>>>> for the Matrix 1.6-2 release if it is really a barrier for others ...
>>>>
>>>> Mikael
>>>>
>>>> On 2023-10-31 3:33 pm, Simon Urbanek wrote:
>>>>> Mikael,
>>>>> current Matrix fails checks on R-oldrel so that's why only the last
>>>>> working version is installed:
>>>>> https://cran.r-project.org/web/checks/check_results_Matrix.html
>>>>&g
Re: [R-pkg-devel] Matrix and Mac OS
On 2023-11-01 12:59 pm, Mikael Jagan wrote:
A hack that seems to work is (whitespace added for readability):
\newcommand{\Seqn}{
\ifelse{latex}{
\Sexpr[results=rd]{if (getRversion() < "4.2.2") "eqn{#1}" else
"eqn{#2}"}
}{
\ifelse{html}{
\Sexpr[results=rd]{if (getRversion() < "4.2.0") "eqn{#1}"
else "eqn{#2}"}
}{
\Sexpr[results=rd]{"eqn{#2}"}
}
}
}
Er, the above is wrong, because '<' should be '>=' and because '#2' (which
is conceptually verbatim text) should use \verb{} for PDF and HTML output,
not \eqn{}. For Matrix 1.6-2 I have created man/macros/local.Rd and added:
\newcommand{\Seqn}{\ifelse{latex}{\Sexpr[results=rd]{if (getRversion() >=
"4.2.2") "eqn{#1}" else
"verb{#2}"}}{\ifelse{html}{\Sexpr[results=rd]{if (getRversion() >=
"4.2.0") "eqn{#1}" else
"verb{#2}"}}{\Sexpr[results=rd]{"eqn{#2}"
\newcommand{\Sdeqn}{\ifelse{latex}{\Sexpr[results=rd]{if (getRversion() >=
"4.2.2") "deqn{#1}" else
"preformatted{#2}"}}{\ifelse{html}{\Sexpr[results=rd]{if (getRversion()
>= "4.2.0") "deqn{#1}" else
"preformatted{#2}"}}{\Sexpr[results=rd]{"deqn{#2}"
Now Matrix 1.6-2 passes its Rd checks under my checkout of R-3-5-branch.
Some examples and tests fail for unrelated reasons. I'll fix those, too ...
Mikael
as amsmath support for PDF output and KaTeX support for HTML output
were introduced in R 4.2.2 and 4.2.0, respectively.
Sadly I really do seem to need 8 escapes:
\Seqn{text{min}(m,n) times n}{min(m,n)-by-n}
Maybe one of the Rd experts here can suggest an improvement ...
Mikael
On 2023-11-01 5:06 am, Martin Maechler wrote:
Uwe Ligges
on Wed, 1 Nov 2023 06:26:23 +0100 writes:
> On 01.11.2023 03:51, Mikael Jagan wrote:
>> Thanks. It seems that we were mistaken in our feeling (IIRC) that it
would
>> be "OK" to implicitly require '--no-manual' on versions of R from
3.5.0 to
>> 4.2.1, not changing our Depends.
>>
>> We will fix this in Matrix 1.6-2, probably by conditionalizing or
otherwise
>> replacing the amsmath commands and probably _not_ by changing to
depend on
>> R >= 4.2.2. Martin may have more to say in "the morning".
I agree (*not* to raise Matrix pkg's R version dependency).
> Note that dependin on R >= 4.2.2 does not work. We need dependencies of
> the form R >= x.y.0. This is also part of the checks.
Yes, indeed.
And as we learned, R >= 4.2.0 would not help for r-oldrel-macos
I (am unhappy but) agree to take the responsibility for our
decision to go ahead and use much nicer LaTeX formula for
matrices etc, in our help pages {thinking that indeed people who'd
install Matrix on an old R version would always be able to read
Matrix manual pages via web search (as it seems to me 95% of
people do nowadays) ... or then have someone in their
organization to figure out how to use a newer amsmath (latex) package if
they really really want the Matrix pdf manual offline}.
Martin
> Reason is that we have only one binary repository for one R-x.y.?
> series. On WIndows, where we check with R-4.2.3, a binary would be
> created and hence R-4.2.[0-1] would not see any valid Matrix binaries.
> So please either make this work on R >= 4.2.0 or require R >= 4.3.0. If
> the latter, ideally with an interim version that works for R >= 4.2.0,
> so that we valid binaries with correct dependency declarations again.
> Best,
> Uwe
>> In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may
>> help
>> to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey
revert its
>> strict version requirement, unless there are clear examples justifying
one.
>>
>> Mikael
>>
>>
>> On 2023-10-31 8:17 pm, Simon Urbanek wrote:
>>> Mikael,
>>>
>>> in that case I think your requirements are wrong - Matrix says R >=
>>> 3.5.0 which is apparently incorrect - from what you say it should be
>>> 4.2.2?. I can certainly update to 4.2.3 if necessary.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>
>>>> On 1/11/2023, at 9:19 AM, Mikael Jagan wrote:
>>>>
>>>> Thanks. We d
Re: [R-pkg-devel] Matrix and Mac OS
Thanks. It seems that we were mistaken in our feeling (IIRC) that it would be "OK" to implicitly require '--no-manual' on versions of R from 3.5.0 to 4.2.1, not changing our Depends. We will fix this in Matrix 1.6-2, probably by conditionalizing or otherwise replacing the amsmath commands and probably _not_ by changing to depend on R >= 4.2.2. Martin may have more to say in "the morning". In the mean time (i.e., while we are stuck with Matrix 1.6-1.1), it may help to update to R 4.2.3 on r-oldrel-macos-* and/or to have EdSurvey revert its strict version requirement, unless there are clear examples justifying one. Mikael On 2023-10-31 8:17 pm, Simon Urbanek wrote: Mikael, in that case I think your requirements are wrong - Matrix says R >= 3.5.0 which is apparently incorrect - from what you say it should be 4.2.2?. I can certainly update to 4.2.3 if necessary. Cheers, Simon On 1/11/2023, at 9:19 AM, Mikael Jagan wrote: Thanks. We did see those ERRORs, stemming from use (since Matrix 1.6-0) of amsmath commands in Rd files. These have been supported since R 4.2.2, but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R 4.2.0. My expectation was that those machines would begin running R >= 4.2.2 well before the R 4.4.0 release, but apparently that was wrong. I am hesitant to complicate our Rd files with conditions on R versions only to support PDF output for R < 4.2.2, but maybe we can consider it for the Matrix 1.6-2 release if it is really a barrier for others ... Mikael On 2023-10-31 3:33 pm, Simon Urbanek wrote: Mikael, current Matrix fails checks on R-oldrel so that's why only the last working version is installed: https://cran.r-project.org/web/checks/check_results_Matrix.html Cheers, Simon On 1/11/2023, at 4:05 AM, Mikael Jagan wrote: I am guessing that they mean EdSurvey: https://cran.r-project.org/web/checks/check_results_EdSurvey.html Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64, even though it can be, because it was not released until R 4.3-z. AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and even those changes should have been backwards compatible, modulo handling of dimnames (class sparseQR gained a Dimnames slot in 1.6-0). So I don't see a clear reason for requiring 1.6-1.1. Requiring 1.6-0 might make sense, if somehow EdSurvey depends on how class sparseQR preserves dimnames. But IIRC our rev. dep. checks at that time did not reveal problems with EdSurvey. Mikael On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote: Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel wrote: Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[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] Matrix and Mac OS
Thanks. We did see those ERRORs, stemming from use (since Matrix 1.6-0) of amsmath commands in Rd files. These have been supported since R 4.2.2, but r-oldrel-macos-* (unlike r-oldrel-windows-*) continues to run R 4.2.0. My expectation was that those machines would begin running R >= 4.2.2 well before the R 4.4.0 release, but apparently that was wrong. I am hesitant to complicate our Rd files with conditions on R versions only to support PDF output for R < 4.2.2, but maybe we can consider it for the Matrix 1.6-2 release if it is really a barrier for others ... Mikael On 2023-10-31 3:33 pm, Simon Urbanek wrote: Mikael, current Matrix fails checks on R-oldrel so that's why only the last working version is installed: https://cran.r-project.org/web/checks/check_results_Matrix.html Cheers, Simon On 1/11/2023, at 4:05 AM, Mikael Jagan wrote: I am guessing that they mean EdSurvey: https://cran.r-project.org/web/checks/check_results_EdSurvey.html Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64, even though it can be, because it was not released until R 4.3-z. AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and even those changes should have been backwards compatible, modulo handling of dimnames (class sparseQR gained a Dimnames slot in 1.6-0). So I don't see a clear reason for requiring 1.6-1.1. Requiring 1.6-0 might make sense, if somehow EdSurvey depends on how class sparseQR preserves dimnames. But IIRC our rev. dep. checks at that time did not reveal problems with EdSurvey. Mikael On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote: Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel wrote: Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[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] Matrix and Mac OS
Re-sending to the list with correct subject line ... I should undigest myself ... Mikael On 2023-10-31 11:05 am, Mikael Jagan wrote: I am guessing that they mean EdSurvey: https://cran.r-project.org/web/checks/check_results_EdSurvey.html Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64, even though it can be, because it was not released until R 4.3-z. AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and even those changes should have been backwards compatible, modulo handling of dimnames (class sparseQR gained a Dimnames slot in 1.6-0). So I don't see a clear reason for requiring 1.6-1.1. Requiring 1.6-0 might make sense, if somehow EdSurvey depends on how class sparseQR preserves dimnames. But IIRC our rev. dep. checks at that time did not reveal problems with EdSurvey. Mikael On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote: Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel wrote: Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[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] R-package-devel Digest, Vol 102, Issue 27
I am guessing that they mean EdSurvey: https://cran.r-project.org/web/checks/check_results_EdSurvey.html Probably Matrix 1.6-1.1 is not installed on r-oldrel-macos-arm64, even though it can be, because it was not released until R 4.3-z. AFAIK, methods for 'qr' have not been touched since Matrix 1.6-0, and even those changes should have been backwards compatible, modulo handling of dimnames (class sparseQR gained a Dimnames slot in 1.6-0). So I don't see a clear reason for requiring 1.6-1.1. Requiring 1.6-0 might make sense, if somehow EdSurvey depends on how class sparseQR preserves dimnames. But IIRC our rev. dep. checks at that time did not reveal problems with EdSurvey. Mikael On 2023-10-31 7:00 am, r-package-devel-requ...@r-project.org wrote: Paul, can you give us a bit more detail? Which package, which build and where you got the errors? Older builds may not have the latest Matrix. Cheers, Simon On 31/10/2023, at 11:26 AM, Bailey, Paul via R-package-devel wrote: Hi, I'm the maintainer for a few packages, one of which is currently failing CRAN checks on Mac OS because Matrix is not available in my required version (the latest). I had to fix a few things due to changes in the latest Matrix package because of how qr works and I thought, given the apparent API change, I should then require the latest version. My error is, "Package required and available but unsuitable version: 'Matrix'" When I look at the NEWS in Matrix there is no mention of Mac OS issues, what the latest stable version of Matrix is, nor when a fix is expected. What version do MacOS version test Matrix with by default? Where is this documented? I assumes it always tested with the latest version on CRAN, so I'm a bit surprised. Or will this be resolved soon and I shouldn't bother CRAN maintainers with a new version of my package? Best, Paul [[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] Question regarding listing base and recommended packages programmatically and efficiently
Maybe something like this:
> isRecommendedPkg <- utils:::isBasePkg
> body(isRecommendedPkg)[[c(3L, 3L)]] <- "recommended"
> installed <- unique(list.files(.libPaths()))
> installed[vapply(installed, isRecommendedPkg, NA)]
[1] "KernSmooth" "MASS" "Matrix" "boot" "class"
[6] "cluster""codetools" "foreign""lattice""mgcv"
[11] "nlme" "nnet" "rpart" "spatial""survival"
where in your package you would define isRecommendedPkg "manually".
Another (but quite undocumented and so maybe not "recommended" :-))
possibility is this:
> mk <- file.path(R.home("share"), "make", "vars.mk")
> pp <- sub("^.*= +", "", grep("^R_PKGS_RECOMMENDED", readLines(mk), value
= TRUE))
> sort(strsplit(pp, " ")[[1L]])
[1] "KernSmooth" "MASS" "Matrix" "boot" "class"
[6] "cluster""codetools" "foreign""lattice""mgcv"
[11] "nlme" "nnet" "rpart" "spatial""survival"
I grepped around and did not find variables in any base namespace containing
the names of these packages. It wouldn't be too hard to define such variables
when R is configured/built, but maybe there are "reasons" to not do that ... ?
Mikael
> It would be much faster (but slightly less reliable) to use
> list.files(.libPaths()) to get the names of all installed packages, and
> then filter them to the known list of base and recommended packages,
> which changes very rarely.
>
> Duncan Murdoch
>
> On 12/10/2023 8:34 a.m., Tony Wilkes wrote:
> > Dear all,
> >
> > In my R package that I'm developing, I use `installed.packages(priority =
"base")` to programmatically get all core/base R packages (i.e. base, stats,
etc.). And similarly, I use installed.packages(priority = "recommended")` to
programmatically get the recommended R packages (i.e. mgcv, lattice, etc.).
> >
> > However, CRAN has requested to not use `installed.packages()`, as it is
slow. I fully get and agree with that assesment. I used installed.packages()`
anyway because I could not find a better, fool-proof alternative.
> >
> > Nonetheless, I was asked to change this code for optimalisation. So I would
like to ask: how do I programmatically get all base/core R packages safely and
efficiently, but without using `installed.packages()`? And the same question for
recommended R packages. I have of course Googled it, and looked at R's
documentation (though R's documentation is large, so it's easy to miss
something); no solution found. So if any of you has a smart idea: I'm all ears.
> >
> > Thank you in advance.
> >
> > Kind regards,
> >
> > Tony.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: no function found corresponding to methods exports for show
On 2023-10-08 5:43 pm, Mikael Jagan wrote:
Hi,
I recently submitted my first R package to CRAN, and I encountered a NOTE
during the checking process. The NOTE looks like this:
=
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: whether the namespace can be loaded with stated dependencies,
Result: NOTE
Warning: no function found corresponding to methods exports from 'hmsr'
for: 'show'
A namespace must be able to be loaded with just the base namespace
loaded: otherwise if the namespace gets loaded by a saved object, the
session will be unable to start.
Probably some imports need to be declared in the NAMESPACE file.
Sounds like your NAMESPACE is missing importFrom(methods, show) ... ?
I'm not sure why you could not reproduce the problem locally, given that
check uses _R_CHECK_CODE_USAGE_WITH_ONLY_BASE_ATTACHED_=true by default.
Reading tools:::.check_packages I see that this environment variable is
not relevant to this particular test. Still, do import generic functions
for which you define methods, from all packages != "base".
Mikael
But it is hard to say anything without a link to the package sources ...
Mikael
=
I'm seeking help to understand and address this issue. show is defined like
this:
#' Show method for class "hms".#'#' @param object - hms s4 object#'#'
@return It returns the names of the slots and the classes associated
with the#' slots in the "hms" class. It prints call details.#'#'
@export#'#' @examples
#' f <- function(x) x
#' result <- hms(fitness = f, lower = -5, upper = 5)
#' show(result)
setMethod("show", "hms", function(object) {
cat("An object of class \"hms\"\n")
cat("\nCall:\n", deparse(object@call), "\n\n", sep = "")
cat("Available slots:\n")
print(methods::slotNames(object))})
And in the NAMESPACE there is a line that looks like this:
exportMethods(show)
I was investigating if the show is defined correctly and the GA package has
a very similar method:
setMethod("show", "ga",function(object)
{ cat("An object of class \"ga\"\n")
cat("\nCall:\n", deparse(object@call), "\n\n",sep="")
cat("Available slots:\n")
print(slotNames(object))})
I could not reproduce this NOTE on my personal machine with Windows.
On Mac OS I have never experienced this NOTE.
Best regards
Wojciech Achtelik
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Note: no function found corresponding to methods exports for show
Hi,
I recently submitted my first R package to CRAN, and I encountered a NOTE
during the checking process. The NOTE looks like this:
=
Flavor: r-devel-linux-x86_64-debian-gcc, r-devel-windows-x86_64
Check: whether the namespace can be loaded with stated dependencies,
Result: NOTE
Warning: no function found corresponding to methods exports from 'hmsr'
for: 'show'
A namespace must be able to be loaded with just the base namespace
loaded: otherwise if the namespace gets loaded by a saved object, the
session will be unable to start.
Probably some imports need to be declared in the NAMESPACE file.
Sounds like your NAMESPACE is missing importFrom(methods, show) ... ?
I'm not sure why you could not reproduce the problem locally, given that
check uses _R_CHECK_CODE_USAGE_WITH_ONLY_BASE_ATTACHED_=true by default.
But it is hard to say anything without a link to the package sources ...
Mikael
=
I'm seeking help to understand and address this issue. show is defined like
this:
#' Show method for class "hms".#'#' @param object - hms s4 object#'#'
@return It returns the names of the slots and the classes associated
with the#' slots in the "hms" class. It prints call details.#'#'
@export#'#' @examples
#' f <- function(x) x
#' result <- hms(fitness = f, lower = -5, upper = 5)
#' show(result)
setMethod("show", "hms", function(object) {
cat("An object of class \"hms\"\n")
cat("\nCall:\n", deparse(object@call), "\n\n", sep = "")
cat("Available slots:\n")
print(methods::slotNames(object))})
And in the NAMESPACE there is a line that looks like this:
exportMethods(show)
I was investigating if the show is defined correctly and the GA package has
a very similar method:
setMethod("show", "ga",function(object)
{ cat("An object of class \"ga\"\n")
cat("\nCall:\n", deparse(object@call), "\n\n",sep="")
cat("Available slots:\n")
print(slotNames(object))})
I could not reproduce this NOTE on my personal machine with Windows.
On Mac OS I have never experienced this NOTE.
Best regards
Wojciech Achtelik
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN index replaces ampersand in BugReports URL with HTML entity
Hello, It was raised on the Matrix bug tracker [1] that the BugReports URL on the CRAN index [2] is broken. The URL in our DESCRIPTION file [3] is fine, but contains an ampersand, which is improperly replaced with the corresponding HTML entity in the HTML sources of the index. Hence this does not affect bug.report(package="Matrix"), but _does_ make our bug tracker inaccessible to people accustomed to visiting the CRAN page for links. Can this be repaired? Mikael [1] https://r-forge.r-project.org/tracker/?func=detail=6787_id=61=294 [2] https://cran.r-project.org/package=Matrix [3] https://r-forge.r-project.org/tracker/?atid=294_id=61 __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
