"Suggests" means that package is required for only for some specific optional things. The functionality of limma used by the majority of users works without the statmod package, hence it is only suggested.
The philosophy of limma is to be a quick install. I don't see the point of burdening everyone with the installation of a lot of optional packages that most times are not needed. I could easily have made an exception for statmod, which is a very lean package and not much overhead, but I wanted to be consistent.
Does this inconvenience you? The error message seems pretty clear and helpful.
Update seven years later (2 August 2023)
limma now imports statmod instead of just suggesting it.
FWIW maybe "statmod package required but is not installed" would be more appropriate. Following R/CRAN terminology a package is available when it's reported by available.packages() and installed after it has gone thru install.packages(). Well, I wish they'd stick to their own terminology but they don't:
hpages@latitude:~$ Rbiocdev CMD INSTALL MyAwesomePackage_1.1.6.tar.gz
* installing to library ‘/home/hpages/R/R-3.3.r70604/library’
ERROR: dependency ‘toto’ is not available for package ‘MyAwesomePackage’
* removing ‘/home/hpages/R/R-3.3.r70604/library/MyAwesomePackage’
Or, after installing package toto:
hpages@latitude:~$ Rbiocdev CMD check MyAwesomePackage_1.1.6.tar.gz
* using log directory ‘/home/hpages/svn/bioconductor/Rpacks/MyAwesomePackage.Rcheck’
* using R version 3.3.0 Patched (2016-05-12 r70604)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘MyAwesomePackage/DESCRIPTION’ ... OK
* this is package ‘MyAwesomePackage’ version ‘1.1.6’
* package encoding: UTF-8
* checking package namespace information ... OK
* checking package dependencies ... ERROR
Package suggested but not available: ‘titi’
...
You make a good point, but it's hard to be very precise with this. I worded the error message as I did (many years ago) because I wanted to use the same wording as given by R core functions in similar contexts (as illustrated by the two examples you give).
I admit that the limma error message is using "available" to mean "installed and loadable" rather than in the sense of available.packages(). However I'm not sure that the documentation for available.packages() is intended to prevent the word "available" from having other meanings in other contexts. In other words, being "available for installation" doesn't necessarily imply "available for loading". The Section on "Suggested packages" in the "Writing R Extensions" manual uses the word "available" at least once to have exactly the same meaning as in the limma error message (see 4th last line of page 11).
The current error message given by requireNamespace() and similar R core functions is different again. It says "there is no package called ...", for example:
> requireNamespace("locfit")
Loading required namespace: locfit
Failed with error: ‘there is no package called ‘locfit’’
While this error message isn't wrong, I think an inexperienced user might nevertheless find it confusing, because there is a package called locfit on CRAN, it just isn't installed.
Anyway, back to the posted question. I agree with you that "is not installed" would have been a better error message in the OP's case. The statmod package has no dependencies other than R core packages, so it should pretty much always load successfully if it is installed.
The same sort of conditional code and error message occurs in the limma package for a number of suggested packages,and the error message is triggered whenever requireNamespace() fails. In the most cases the error means that the required package is not installed, but it can also occur when the required package is installed but cannot be loaded for some reason, perhaps because one of the dependencies of that package cannot be loaded. For example biocLite() successfully installs vsn, but the package can't be loaded without extra work:
> biocLite("vsn")
> find.package("vsn")
[1] "C:/lib/R/R-3.3.0/library/vsn"
> library(vsn)
Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]) :
there is no package called ‘plyr’
Error: package or namespace load failed for ‘vsn’
I suppose I could change the error message to say "Package X is required but is not installed (or can't be loaded)".
I like "Package X is required but is not installed (or can't be loaded)". Sounds like a pretty accurate description of the situation. I think I'll use this in my own code too.
Too bad that standard tools like library/loadNamespace/requireNamespace/attachNamespace don't display something like that. If they were, then we wouldn't need to silently catch their error just for the sake of raising a new error with a reformulated error message. Also too bad that, like R CMD INSTALL and R CMD check, the official documentation is not using the terms available and installed with a meaning that is consistent with the available.packages/install.packages/installed.packages functions :-/
I'm trying to create an scripted build/installation of a bundle of CRAN packages, which includes Limma. I'm using information from the BioC Debian Control File (DFC; https://bioconductor.org/packages/3.2/bioc/src/contrib/PACKAGES) to build a dependency graph so that I can automate the install BioC and CRAN dependencies of the specified packages. I am currently installing packages specified by the "Depends" and "Imports" prior to the package itself. The error message is helpful, but only at some future point in time as to when a user runs that function.
Initially my opinion on Limma specifying statmod as a "Suggests" was that it does not accurately reflect the true relationship between Limma and statmod. Surely, if a function doesn't work without a package being installed, then the package is a "Depends" and not a "Suggests". To hide this relationship, so as to reduce the install footprint, seems to be a misuse of the dependency system.
Having a look at the BioC Package Guidelines doc, it states:
Suggests: is for packages used in vignettes or examples, or in conditional code.
Depends: is for packages that provide essential functionality for users of your package, e.g., the GenomicRanges package is listed in the Depends: field of GenomicAlignments. It is unusual for more than three packages to be listed as ‘Depends:’.
I would argue that "conditional code" in the "Suggests" means there is an alternative path through the code, which provides the same behaviour, if the suggested package is not installed. I would argue that it doesn't mean a package is a "Suggests" if that branch of the code is not frequently executed by the users. The suggestion that having more than 3 dependencies specified in "Depends" seems very odd to me! But that's for another time!
Anyway, in a nutshell, performing an scripted install of specified dependencies using info from the above DCF will result in a "broken" Limma install since not all functions can be executed successfully if a dependency is specified as a "suggests". I loath to also install all "Suggests" packages as this will really blow out my install footprint my 100's (1000's) or packages and have way more points of failure to contend with.
Mostly for other developers who may be reading this thread, from the package guidelines the alternative location for statmod would be in 'Imports' rather than 'Depends', since the functionality provided is internal to the package. The guidelines are broadly similar to R's own instructions.
People frequently follow vignettes or man page examples, and these often require (in the English language sense of the word) packages listed in Suggests:. A scripted install that does not include Suggests: packages is already making decisions about the extent to which a package will be supported 'out of the box'. An interesting further example might be code that uses an AnnotationData package (e.g., one of the org.*, TxDb.*, or BSgenome.* packages or any of the microarray chip packages) without explicitly naming it -- the code will only work reliably when all such packages are installed!
In other words, you are not inconvenienced and there is no actual problem to be solved. You could easily just choose to install statmod as part of your script.
Your idiosyncratic definition what a "suggested" package should be is too restrictive to be useful. Your definition could only apply to packages that offer speed-up (multi-threading, sparse arithmetic etc) instead of functionality or resources. If I applied your definition to limma, then limma would be not be usable at all without loading a host of packages including just about every organism annotation package. This would inconvenience everyone including you.
From your post, it seems that you may not be familiar with recent developments regarding name spaces and imported packages. If you look into that, you will understand the reason for the three package guidance regarding Depends. (If you run R CMD check on your own package PCIT, you will find that it no longer satisfies the minimum CRAN requirements regarding package declarations.)
This support forum is intended for users to ask questions. I don't mean any offense, but if you did ask some questions instead of just offering opinions, that might be a more effective way to learn what others are trying to achieve.
Hi Gordon,
FWIW maybe "statmod package required but is not installed" would be more appropriate. Following R/CRAN terminology a package is available when it's reported by
available.packages()and installed after it has gone thruinstall.packages(). Well, I wish they'd stick to their own terminology but they don't:Or, after installing package toto:
So never mind...
Cheers,
H.
Hi H,
You make a good point, but it's hard to be very precise with this. I worded the error message as I did (many years ago) because I wanted to use the same wording as given by R core functions in similar contexts (as illustrated by the two examples you give).
I admit that the limma error message is using "available" to mean "installed and loadable" rather than in the sense of
available.packages(). However I'm not sure that the documentation foravailable.packages()is intended to prevent the word "available" from having other meanings in other contexts. In other words, being "available for installation" doesn't necessarily imply "available for loading". The Section on "Suggested packages" in the "Writing R Extensions" manual uses the word "available" at least once to have exactly the same meaning as in the limma error message (see 4th last line of page 11).The current error message given by
requireNamespace()and similar R core functions is different again. It says "there is no package called ...", for example:> requireNamespace("locfit") Loading required namespace: locfit Failed with error: ‘there is no package called ‘locfit’’While this error message isn't wrong, I think an inexperienced user might nevertheless find it confusing, because there is a package called locfit on CRAN, it just isn't installed.
Anyway, back to the posted question. I agree with you that "is not installed" would have been a better error message in the OP's case. The statmod package has no dependencies other than R core packages, so it should pretty much always load successfully if it is installed.
The same sort of conditional code and error message occurs in the limma package for a number of suggested packages,and the error message is triggered whenever
requireNamespace()fails. In the most cases the error means that the required package is not installed, but it can also occur when the required package is installed but cannot be loaded for some reason, perhaps because one of the dependencies of that package cannot be loaded. For examplebiocLite()successfully installs vsn, but the package can't be loaded without extra work:> biocLite("vsn") > find.package("vsn") [1] "C:/lib/R/R-3.3.0/library/vsn" > library(vsn) Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]) : there is no package called ‘plyr’ Error: package or namespace load failed for ‘vsn’I suppose I could change the error message to say "Package X is required but is not installed (or can't be loaded)".
Hi Gordon,
I like "Package X is required but is not installed (or can't be loaded)". Sounds like a pretty accurate description of the situation. I think I'll use this in my own code too.
Too bad that standard tools like
library/loadNamespace/requireNamespace/attachNamespacedon't display something like that. If they were, then we wouldn't need to silently catch their error just for the sake of raising a new error with a reformulated error message. Also too bad that, likeR CMD INSTALLandR CMD check, the official documentation is not using the terms available and installed with a meaning that is consistent with theavailable.packages/install.packages/installed.packagesfunctions :-/H.
I'm trying to create an scripted build/installation of a bundle of CRAN packages, which includes Limma. I'm using information from the BioC Debian Control File (DFC; https://bioconductor.org/packages/3.2/bioc/src/contrib/PACKAGES) to build a dependency graph so that I can automate the install BioC and CRAN dependencies of the specified packages. I am currently installing packages specified by the "Depends" and "Imports" prior to the package itself. The error message is helpful, but only at some future point in time as to when a user runs that function.
Initially my opinion on Limma specifying statmod as a "Suggests" was that it does not accurately reflect the true relationship between Limma and statmod. Surely, if a function doesn't work without a package being installed, then the package is a "Depends" and not a "Suggests". To hide this relationship, so as to reduce the install footprint, seems to be a misuse of the dependency system.
Having a look at the BioC Package Guidelines doc, it states:
Suggests: is for packages used in vignettes or examples, or in conditional code.
Depends: is for packages that provide essential functionality for users of your package, e.g., the
GenomicRangespackage is listed in the Depends: field ofGenomicAlignments. It is unusual for more than three packages to be listed as ‘Depends:’.I would argue that "conditional code" in the "Suggests" means there is an alternative path through the code, which provides the same behaviour, if the suggested package is not installed. I would argue that it doesn't mean a package is a "Suggests" if that branch of the code is not frequently executed by the users. The suggestion that having more than 3 dependencies specified in "Depends" seems very odd to me! But that's for another time!
Anyway, in a nutshell, performing an scripted install of specified dependencies using info from the above DCF will result in a "broken" Limma install since not all functions can be executed successfully if a dependency is specified as a "suggests". I loath to also install all "Suggests" packages as this will really blow out my install footprint my 100's (1000's) or packages and have way more points of failure to contend with.
I suggest statmod be specified as a "Depends".
Mostly for other developers who may be reading this thread, from the package guidelines the alternative location for statmod would be in 'Imports' rather than 'Depends', since the functionality provided is internal to the package. The guidelines are broadly similar to R's own instructions.
People frequently follow vignettes or man page examples, and these often require (in the English language sense of the word) packages listed in Suggests:. A scripted install that does not include Suggests: packages is already making decisions about the extent to which a package will be supported 'out of the box'. An interesting further example might be code that uses an AnnotationData package (e.g., one of the org.*, TxDb.*, or BSgenome.* packages or any of the microarray chip packages) without explicitly naming it -- the code will only work reliably when all such packages are installed!
In other words, you are not inconvenienced and there is no actual problem to be solved. You could easily just choose to install statmod as part of your script.
Your idiosyncratic definition what a "suggested" package should be is too restrictive to be useful. Your definition could only apply to packages that offer speed-up (multi-threading, sparse arithmetic etc) instead of functionality or resources. If I applied your definition to limma, then limma would be not be usable at all without loading a host of packages including just about every organism annotation package. This would inconvenience everyone including you.
From your post, it seems that you may not be familiar with recent developments regarding name spaces and imported packages. If you look into that, you will understand the reason for the three package guidance regarding Depends. (If you run R CMD check on your own package PCIT, you will find that it no longer satisfies the minimum CRAN requirements regarding package declarations.)
This support forum is intended for users to ask questions. I don't mean any offense, but if you did ask some questions instead of just offering opinions, that might be a more effective way to learn what others are trying to achieve.