-
Notifications
You must be signed in to change notification settings - Fork 987
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
Encourage Imports not Depends #3076
Comments
It shouldn't be disallowed because there are valid use cases for Depends, for example my package dtq which is a logging mechanism for |
Fair enough. Why exactly is it that those packages need Depends and can't use Imports? |
They are extensions of data.table, their existence without data.table is pointless. They not just "use" data.table. |
I still don't follow. Importing is as strong as depending in that imports are required. No package importing data.table can install without it. What would fail if they changed to Imports? There is also |
It is as strong, except the fact that imported namespace doesn't need to be attached. It doesn't mask, but it expects data.table to be attached. There are definitely very few use cases like this so general rule should be to import. |
75 maintainers emailed today (up from the 69 in Sep 2018) : deps = tools::package_dependencies("data.table", which="Depends", reverse=TRUE)[[1]]
paste(sapply(deps, maintainer),collapse=";")
|
Depends:
; require Imports:
only.
First of all thanks a ton for reaching out to the package maintainers. I fully agree. I always use data.table for my backends and have imported on my more recent packages. In my case panelaggregation was a try to put a package on CRAN back when people wore pyjamas and lived life slow. Last time a data.table change caused issues I tried to get the package of CRAN but was discouraged to do so. I'd rather put my time into my newer packages than to fix a package which is more or less abandoned. On the other hand it would probably not be that much of deal to fix it though I haven't looked at the package in years. Bottom line: from my point of view, disallowing would be a bit too much since it would get my old package of CRAN forcefully. |
hi I just updated my penaltyLearning package, tdhock/penaltyLearning@ef8e7fb. now it imports data.table instead of depends. basically I just had to add a bunch of library(data.table) lines in tests and examples. |
Hi thanks for the email and for data.table Best |
Adding these from Bioconductor:
Also added some code for repeating this & some more new packages from CRAN under |
And updated files to pass devtools::check()
tcpl package has moved data.table to imports |
Reminder email sent today to these 74 :
|
Updated |
Added badges of Depends/Imports count to first post. They are being refreshed daily. |
Hi, @mattdowle Thank you for the notice, and the wonderful data.table package. I experienced inconsistent solution for communicating with Rcpp, when used imports instead of depends. This could caused by other issues. But at that time, depends is a reasonable choice as the package relied on and built around data.table features. Let me test on imports and get back to you. Thank you. |
Thanks for the reminder! Should be done for the sentometrics package by next CRAN release. Sam |
Hello, Regards |
Hello, This is fixed in JWileymisc now propagating through CRAN. I took the opportunity to change all depends into imports. Cheers, Josh |
|
Removing the packages from Depends on DESCRIPTION required adding @importsFrom and @export across all functions, hence this commit slightly modifies the entire codebase. Vignettes were edited to require() instead of attaching using library() following best practies. Rather than copy and paste data.table across all functions, I followed XGBoost package approach and loaded only on a single file. Since all codebase wont work without parsers, that seem the most logical place. Other more situational dependence on functions will use the typical :: approach which is hard for data.table. Arguably data.table could belong on Depends, but even the package maintainer argues against it, see: Rdatatable/data.table#3076
Currently 79 packages that Depend rather than Import and they continue to be created or updated.
I never did get to the bottom of Jan's objections above to deprecating (very gently and slowly over several years) Depend'ing; i.e. what the valid use cases of Depend'ing are: why Import'ing won't work or is not as good as Depend'ing. |
CRAN + BioC:
I've only recently realized how bad
Depends:
is, thanks to Jan's importing vignette. I just made its discouragement stronger : 51590bcWe could disallow Depends. This would also be beneficial to
cedta()
's awkward implementation on its last line where it needs to do the tryCatch just for packages which Depend; that line could be removed.But before we disallow Depends, we'd need to ask 69 CRAN packages to change from Depends to Imports. (Most revdeps already Import.) The longer we leave it, the greater the potential for new packages using Depends to be added to CRAN and the harder it will be to change.
Check when changed to Imports and published on CRAN too :
edgeRunremoved from CRANhaploReconstructremoved from CRANQuantToolsremoved from CRANRbitcoinremoved from CRANRnetsremoved from CRANstrangerremoved from CRANttwaremoved from CRANUNCONTACTED AS OF 2019-08-13
Quick links to CRAN index of all packages:
Ac3net AF batchtools bea.R behavr BuyseTest cdparcoord classifierplots clickstream corpustools CoSMoS cvAUC damr dfmeta drgee easycsv EBPRS edgeRun EurosarcBayes gbp GenomicTools GenomicTools.fileHandler GenoScan glmaag greport haploReconstruct heims ie2misc iemisc JWileymisc LabourMarketAreas lookupTable lori LSPFP miLineage mrMLM mrMLM.GUI multicastR musica openSTARS orgR panelaggregation partools phenocamapi pkggraph PROSPER QuantTools Rbitcoin rblt reinsureR riskRegression Rnets robCompositions RSauceLabs RWildbook sentometrics shinyML simPop sitreeE skm slim somspace sparseFLMM SVN synthACS TreeLS ttwa Tushare twl validateRS VIM WGScan word.alignment
The text was updated successfully, but these errors were encountered: