Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trim suggested dependencies #5745

Closed
jangorecki opened this issue Nov 20, 2023 · 8 comments
Closed

trim suggested dependencies #5745

jangorecki opened this issue Nov 20, 2023 · 8 comments
Milestone

Comments

@jangorecki
Copy link
Member

jangorecki commented Nov 20, 2023

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
Copy link
Member

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
Copy link
Member Author

jangorecki commented Nov 20, 2023

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

  • regarding rmarkdown I filled add html_vignette function rstudio/markdown#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
Copy link
Contributor

eddelbuettel commented Nov 20, 2023

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
Copy link
Member Author

@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
Copy link
Contributor

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
Copy link
Member Author

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

@jangorecki
Copy link
Member Author

resolved

@jangorecki jangorecki added this to the 1.15.0 milestone Dec 6, 2023
@jangorecki
Copy link
Member Author

jangorecki commented Dec 8, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants