trim suggested dependencies

[jangorecki]

Complete installation of data.table + suggested dependencies results in following packages being installed in a library. While data.table doesn't have any hard dependencies, the soft ones could be trimmed to keep that to the minimum. Not sure how easy, and at what cost, would be possible.

Suggests: bit64 (>= 4.0.0), bit (>= 4.0.4), curl, R.utils, xts, nanotime, zoo (>= 1.8-1), yaml, knitr, rmarkdown, markdown, parallel

including recursive deps, total 38 packages

 [1] "bit"         "R.oo"        "R.methodsS3" "zoo"         "bit64"      
 [6] "RcppCCTZ"    "Rcpp"        "RcppDate"    "evaluate"    "highr"      
[11] "xfun"        "yaml"        "bslib"       "fontawesome" "htmltools"  
[16] "jquerylib"   "jsonlite"    "knitr"       "stringr"     "tinytex"    
[21] "base64enc"   "cachem"      "memoise"     "mime"        "rlang"      
[26] "sass"        "digest"      "ellipsis"    "fastmap"     "cli"        
[31] "glue"        "lifecycle"   "magrittr"    "stringi"     "vctrs"      
[36] "fs"          "R6"          "rappdirs"   

and few of them are quite heavy.
curl package also imposes extra OS dependency , devel version of libcurl.

Broken down by each Suggested dep:

$bit64
[1] "bit"

$bit
character(0)

$curl
character(0)

$R.utils
[1] "R.oo"        "R.methodsS3"

$xts
[1] "zoo"

$nanotime
[1] "bit64"    "RcppCCTZ" "zoo"      "Rcpp"     "RcppDate" "bit"     

$zoo
character(0)

$yaml
character(0)

$knitr
[1] "evaluate" "highr"    "xfun"     "yaml"    

$rmarkdown
 [1] "bslib"       "evaluate"    "fontawesome" "htmltools"   "jquerylib"  
 [6] "jsonlite"    "knitr"       "stringr"     "tinytex"     "xfun"       
[11] "yaml"        "base64enc"   "cachem"      "memoise"     "mime"       
[16] "rlang"       "sass"        "digest"      "ellipsis"    "fastmap"    
[21] "highr"       "cli"         "glue"        "lifecycle"   "magrittr"   
[26] "stringi"     "vctrs"       "fs"          "R6"          "rappdirs" 

[ben-schwen]

I tinkered about removing curl a while ago. Main problem was the support of R 3.1.0. AFAIR R 3.2.0 improved utils::download.files a lot.

[jangorecki]

rmarkdown (many, and some heavy, recursive deps), nanotime (heavy recursive deps) and curl (OS dep) are perfect candidates for removal.

• regarding rmarkdown I filled https://github.com/rstudio/markdown/issues/108

• as for nanotime, I think it is possible. We have fwrite supporting nanotime, but we can still support that without needing to access nanotime namespace. And many tests related to nanotime, which could be migrated to nanotime package, which Suggests on data.table already, so will not add extra overhead. @eddelbuettel remove nanotime suggested dependency #5761

• as for curl, we could even raise an error about unsupported case (fread on url), as it will only affect 3.1.0 users, otherwise it is some reason to bump R dependency, but simply asking (3.1.0) users to download their file from url in error message seems fine to me. Remove curl from suggests #5749

[eddelbuettel]

I too wish nanotime were lighter but it is what it is. The support of nanosecond timestamp in data.table is outstanding; I made great use of that a few years ago when I was dealing with nanosecond financial data. I think it would be hard loss. Basically data.table gives us what xts can do at the POSIXct level ... but at nanoseconds. The whole grouping, indexing, slicing, dicing, ... It's lovely. (And Leo and I have dtts building on top of this.

I went the hard route in a few of my packages and discarded rmarkdown/knitr in favour of lighter alternative but I understand that that is not everybody's coup of tea.

And I concur that we no longer need to cater to users of R 3.1.0.

[jangorecki]

@eddelbuettel support of nanotime in data.table would not change at all, we don't need to access nanotime namespace for that. Only tests require loading nanotime that AFAIK, and those tests could be migrated to nanotime package.

[eddelbuettel]

Doh, I missed the gist of that. No problem, happy to farm some tests out to my side and have them tickle up in reverse-dependency checks.

[ Also, I am in your crosshairs for the coordinated change of renaming the C API access point I once contributed. (I never quite understood why it needed renaming, but I defer to team data.table here.) So if you need me to change that in the 'consuming' package that accesses it I can of course help with a coordinated upload. Either 1.14.10 or 1.15.0. Happy to assist. ]

[jangorecki]

@ben-schwen in case you abandoned your PR branch let us know, curl is now last missing piece to close this issue

[jangorecki]

resolved

[jangorecki]

Currently our most heavy dep is knitr. Fortunately it is not that heavy one. Anyway deps could be further improved if/when https://github.com/rstudio/markdown/issues/109 (knitting vignettes directly from markdown pkg without knitr) will be provided