Skip to content

trim suggested dependencies #5745

Description

@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" 

Activity

  1. ben-schwen commented on Nov 20, 2023

    @ben-schwen
    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.

  2. jangorecki commented on Nov 20, 2023

    @jangorecki
    MemberAuthor

    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

  3. eddelbuettel commented on Nov 20, 2023

    @eddelbuettel
    Contributor

    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.

  4. jangorecki commented on Nov 20, 2023

    @jangorecki
    MemberAuthor

    @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.

  5. eddelbuettel commented on Nov 20, 2023

    @eddelbuettel
    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. ]

  6. jangorecki commented on Dec 6, 2023

    @jangorecki
    MemberAuthor

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

  7. jangorecki commented on Dec 6, 2023

    @jangorecki
    MemberAuthor

    resolved

  8. added this to the 1.15.0 milestone on Dec 6, 2023
  9. jangorecki commented on Dec 8, 2023

    @jangorecki
    MemberAuthor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions