I am using in my Package XlConnect. If the Computer is using Java < 11
all is working. But if not, the package can not be used.
inside teh functions tehre is an ' @importFrom XLConnect createSheet
writeWorksheet saveWorkbook
but only used for additional comfort to use excel sheets
The package is usable without XlConnect if I change
Imports: igraph,chron,gdata, XLConnect
to
Imports:
igraph,chron,gdata
Suggests:XLConnect
but then I get the error
checking package dependencies ... ERROR
Namespace dependency not required: ?XLConnect?
Just now the new version is on my private repository and working with or
without Xlconnect depending on the java version
How can I submit the package to cran until XlConnect is working with
java > 11
REgards Knut
[R-pkg-devel] Used package not updated - needs java < V 11
9 messages · Duncan Murdoch, Spencer Graves, Knut Krueger
On 15/12/2020 8:02 a.m., Knut Krueger wrote:
I am using in my Package XlConnect. If the Computer is using Java < 11
all is working. But if not, the package can not be used.
inside teh functions tehre is an ' @importFrom XLConnect createSheet
writeWorksheet saveWorkbook
but only used for additional comfort to use excel sheets
The package is usable without XlConnect if I change
Imports: igraph,chron,gdata, XLConnect
to
Imports:
igraph,chron,gdata
Suggests:XLConnect
but then I get the error
checking package dependencies ... ERROR
Namespace dependency not required: ?XLConnect?
Just now the new version is on my private repository and working with or
without Xlconnect depending on the java version
How can I submit the package to cran until XlConnect is working with
java > 11
You should not have
@importFrom XLConnect createSheet writeWorksheet saveWorkbook
in your ROxygen comments; that results in an unconditional import.
Instead, you should use fully qualified calls each time, i.e.
XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook
in your code. You should also wrap every use of those functions in
checks like
if (requireNamespace("XLConnect")) {
run code
} else {
report that you can't run that code
}
and make sure none of your examples or vignettes fail if XLConnect is
not present.
Duncan Murdoch
I suggest NOT using "XLConnect". "sos" now uses WriteXLS. "Ecfun" now uses "openxlsx". Also, I received an email from CRAN maintainers months ago saying that "gdata" was being obsoleted. It's still on CRAN with a date of 2017-06-06 and a huge number of reverse dependencies. The CRAN maintainers may have gotten someone to agree to take it over who just hasn't finished fixing whatever deficiencies it has. However, you might see how difficult it might be to do without "gdata" as well. Spencer Graves
On 2020-12-15 07:37, Duncan Murdoch wrote:
On 15/12/2020 8:02 a.m., Knut Krueger wrote:
I am using in my Package XlConnect. If the Computer is using Java < 11 all is working. But if not, the package can not be used. inside teh functions tehre is an ' @importFrom XLConnect createSheet writeWorksheet saveWorkbook but only used for additional comfort to use excel sheets The package is usable without XlConnect if I change Imports:? igraph,chron,gdata, XLConnect to Imports: ????? igraph,chron,gdata Suggests:XLConnect but then I get the error checking package dependencies ... ERROR ??? Namespace dependency not required: ?XLConnect? Just now the new version is on my private repository and working with or without Xlconnect depending on the java version How can I submit the package to cran? until XlConnect is working with java > 11
You should not have
@importFrom XLConnect createSheet writeWorksheet saveWorkbook
in your ROxygen comments; that results in an unconditional import.
Instead, you should use fully qualified calls each time, i.e.
XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook
in your code.? You should also wrap every use of those functions in
checks like
if (requireNamespace("XLConnect")) {
? run code
} else {
? report that you can't run that code
}
and make sure none of your examples or vignettes fail if XLConnect is
not present.
Duncan Murdoch
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
1 day later
Thank you for your answer, I tested WriteXLS and openxlsx ... but it is perl based and most of the Windows user do not have perl installed. Therefore I would change the missing XlConnect with missing Perl library. And that is more complicated, because the user has to add something on operating system level. No chance f.e on University cip pools and users unfamiliar with operating systems at all -> gdata - I will check how to change it Thank you Knut Am 15.12.20 um 15:43 schrieb Spencer Graves:
???? I suggest NOT using "XLConnect".? "sos" now uses WriteXLS. "Ecfun" now uses "openxlsx". ????? Also, I received an email from CRAN maintainers months ago saying that "gdata" was being obsoleted.? It's still on CRAN with a date of 2017-06-06 and a huge number of reverse dependencies.? The CRAN maintainers may have gotten someone to agree to take it over who just hasn't finished fixing whatever deficiencies it has.? However, you might see how difficult it might be to do without "gdata" as well. ????? Spencer Graves
Am 15.12.20 um 14:37 schrieb Duncan Murdoch: thank you for your answer
You should not have @importFrom XLConnect createSheet writeWorksheet saveWorkbook in your ROxygen comments; that results in an unconditional import. Instead, you should use fully qualified calls each time, i.e. XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook
#' @importFrom XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook This causes the error "there is no package called ?XLConnect::createSheet,?" Regards Knut
On 16/12/2020 10:21 a.m., Knut Krueger wrote:
Am 15.12.20 um 14:37 schrieb Duncan Murdoch: thank you for your answer
You should not have @importFrom XLConnect createSheet writeWorksheet saveWorkbook in your ROxygen comments; that results in an unconditional import. Instead, you should use fully qualified calls each time, i.e. XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook
#' @importFrom XLConnect::createSheet, XLConnect::writeWorksheet, XLConnect::saveWorkbook This causes the error "there is no package called ?XLConnect::createSheet,?"
No, you should drop the @importFrom comment completely, and in your R code use those fully qualified forms. Duncan Murdoch
1 day later
????? Also, I received an email from CRAN maintainers months ago saying that "gdata" was being obsoleted.? It's still on CRAN with a date of 2017-06-06 and a huge number of reverse dependencies.? The CRAN maintainers may have gotten someone to agree to take it over who just hasn't finished fixing whatever deficiencies it has.? However, you might see how difficult it might be to do without "gdata" as well. ????? Spencer Graves
Is it permissible to copy the code from rename.vars (gdata) inside my package with an hint: " Function rename.vars Source code from gdata as gdata is unmaintained since 2017-06-06 Rename variables in a dataframe Author(s) Don MacQueen (package gdata), macq\@llnl.gov." it is the only function I am using from gdata. Knut
Am 16.12.20 um 16:57 schrieb Duncan Murdoch: > No, you should drop the @importFrom comment completely, and in your R > code use those fully qualified forms. > > Duncan Murdoch Sorry I did not read carefully Knut
On 2020-12-17 12:22, Knut Krueger wrote:
?????? Also, I received an email from CRAN maintainers months ago saying that "gdata" was being obsoleted.? It's still on CRAN with a date of 2017-06-06 and a huge number of reverse dependencies.? The CRAN maintainers may have gotten someone to agree to take it over who just hasn't finished fixing whatever deficiencies it has.? However, you might see how difficult it might be to do without "gdata" as well. ?????? Spencer Graves
?? Is it permissible to copy the code from rename.vars (gdata) inside my package with an hint: "? Function rename.vars Source code from gdata as gdata is unmaintained since 2017-06-06 Rename variables in a dataframe Author(s) Don MacQueen (package gdata), macq\@llnl.gov." it is the only function I am using from gdata.
That's definitely consistent with the GPL-2 license it carries as long as you aren't trying to charge royalties for use of your package. See: https://CRAN.R-project.org/package=gdata And the tarball is available at this link to make it easy for you to do that. Regarding my earlier comment about to gdata being potentially obsoleted, I don't see evidence of that now: There is only one "Note" in the "CRAN checks", and that would seem to be a problem more with that platform than with the gdata package. The problem that Brian Ripley mentioned in his email about this 2020-09-11 may have been with something else that gdata used that has since been fixed. I would normally prefer to let the gdata maintainers continue to maintain a function like this. However, you seem to have a compelling reason for copying that function and only citing the original for the source of where you got the code. You might include, e.g., \code{\link[gdata]{rename.vars}}. CAVEAT: Please ignore the above if contradicted by someone more knowledgeable than I am about CRAN and R policies and recommendations. Spencer
Knut
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel