Skip to content

[Bioc-devel] CRAN package with Bioconductor dependencies

12 messages · Ryan, Gabriel Becker, Martin Morgan +5 more

Original
Laurent Gatto
# 
Dear all,


I had never realised that CRAN packages that depended on Bioc packages
could actually not be installed with install.packages without setting a
repo or using BiocInstaller::bioLite. Here is an example using a fresh R
installation

  http://cran.r-project.org/web/packages/MSeasy/index.html
  Depends: amap, clValid, cluster, fpc, mzR, xcms

$ docker run --rm -ti rocker/r-base R

R version 3.1.2 (2014-10-31) -- "Pumpkin Helmet"
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
Installing package into ?/usr/local/lib/R/site-library?
(as ?lib? is unspecified)
Warning: dependencies ?mzR?, ?xcms? are not available
also installing the dependencies ?modeltools?, ?DEoptimR?, ?mclust?, ?flexmix?, ?prabclus?, ?diptest?, ?mvtnorm?, ?robustbase?, ?kernlab?, ?trimcluster?, ?amap?, ?clValid?, ?fpc?

[...]

ERROR: dependencies ?mzR?, ?xcms? are not available for package ?MSeasy?
* removing ?/usr/local/lib/R/site-library/MSeasy?

The downloaded source packages are in
	?/tmp/Rtmp4T40ub/downloaded_packages?
Warning message:
In install.packages("MSeasy") :
  installation of package ?MSeasy? had non-zero exit status

This does sound really counter-intuitive. Am I missing anything?

Laurent
Ryan
# 
I thought CRAN packages weren't allowed to depend on Bioconductor 
packages for exactly this reason.
On 03/02/2015 03:18 PM, Laurent Gatto wrote:
Martin Morgan
#
On 03/02/2015 03:18 PM, Laurent Gatto wrote:
biocLite("MSeasy") is easy and works.

Otherwise yes, to install a Bioconductor package using install.packages() 
requires that you've selected (via chooseBioCmirror() or options("BioC_mirror")) 
or provided (e.g., install.packages("MSeasy", 
repos=BiocInstaller::biocinstallRepos()) a Bioconductor repository.

Since the mirror choices provided by chooseBioCmirror() are hard-wired, users of 
R3.0.0 + chooseBioCmirror() will get an older version of Biocondcutor than users 
of 3.0.0 + biocLite().

Martin

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Gabriel Becker
    

    

      
      #
    

  


  

      
Even if it is allowed, what is the reasoning behind not simply putting the
package in Bioconductor? It seems like a fair bit of pain for very little
benefit.

~G

On Mon, Mar 2, 2015 at 3:22 PM, Ryan C. Thompson <rct at thompsonclan.org>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Martin Morgan
    

    

      
      #
    

  


  

      
On 03/02/2015 03:22 PM, Ryan C. Thompson wrote:

            

      
      
      
    

        
CRAN packages can and do depend on Bioconductor packages.

The different versioning schemes use by CRAN and by Bioconductor can lead to 
confusion, and can end in tears.

My advice is to use, and tell your users to use, biocLite() for everything 
(including, in devel, github, e.g., biocLite("mtmorgan/biocdb"), which delegates 
to devtools).

Martin

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Laurent Gatto
    

    

      
      #
    

  


  

      
Thank you all for your answers.

Laurent

        
On  2 March 2015 23:27, Martin Morgan wrote:

        

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
Not that long ago DESCRIPTION field 'Additional_repositories' was
introduced which the purpose of providing references to non-mainstream
package repositories, e.g. R-Forge.  Interestingly, by "mainstream"
they mean CRAN and Bioconductor.  The 'Additional_repositories' field
is also enforced for CRAN depending on non-mainstream packages, where
"depending" on can be any package under "Depends", "Imports",
"Suggests" and (I guess), "LinkingTo" and "Enhances".

I bet that in a, hopefully, not too far future, we'll find that
install.packages() will install from not only CRAN by default, but
also Bioconductor and whatever Additional_repositories suggests.  As
usual, the bet is about food and drinks in person whenever/whenever
feasible.


BTW, I have a few feature requests related to Bioc releases/versions:

1. Add release date to online announcement pages online, e.g.
http://bioconductor.org/news/bioc_2_14_release/


2. A data.frame listing Bioc versions and their release dates (maybe
even time stamps), e.g.

            

      
      
      
    

        
1.0 2002-04-29
...
2.14 2014-10-14
3.0 2014-04-14
3.1 2015-04-17


3. As far as I understand it, the recommended Bioc version to use
depends on R version and the date (in the past only R version).  I
would like to have a function that returns the Bioc version as a
function of R version and date.  Maybe BiocInstaller::biocVersion()
could be extended with this feature, e.g.

biocVersion <- function(date, rversion) {
  ## Current?
  if (missing(date) && missing(rversion)) return(BIOC_VERSION)

  if (missing(date) date <- Sys.date()
  date <- as.Date(date)
  if (missing(rversion)) rversion <- getRversion()

  ## Lookup by (rversion, date) from known releases
  ## and make best guesses for the future (with a warning)
  ...
}

If such a function could be available as a light-weight script online,
then the proper Bioc repos could be "downloaded" by
tools:::.BioC_version_associated_with_R_version(), cf. Martin's reply
on lagging Bioc versions.  This would bring us one step closer to
installing Bioc packages using install.packages(), cf. Laurent's
original post. Because it may not be clear to an R user that they need
to go to Bioconductor because a CRAN package depends on a Bioc
package. That user might not even have heard of Bioconductor. Not
suggesting biocLite() should be replaced, but the gap for using
install.packages() could be made smaller.  ... and maybe one day we'll
have an omnibus package installer/updater available in a fresh R
installation.

The above biocVersion() function would also be useful for figuring out
what R/BioC version was in use at a certain year in the past (e.g.
reproducing old work) and for finding out versions of Bioc
release/devel packages back in time (e.g. if you try to be backward
compatible).

Thxs,

Henrik

        
On Mon, Mar 2, 2015 at 3:41 PM, Laurent Gatto <lg390 at cam.ac.uk> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Laurent Gatto
    

    

      
      #
    

  


  

      
On  3 March 2015 06:07, Henrik Bengtsson wrote:

        

            

      
      
      
    

        
Thanks, Henrik!

If I understand well, Bioconductor is considered a mainstream repository
and so is not expected to be added as an Additional_repository (despite
the fact that install.packages does not install the Bioc repository by
default). The issues with doing so nevertheless would be that CRAN
maintainer might complaind and this would break the tied R/Bioc
versions.

Best wishes,

Laurent

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kevin Coombes
    

    

      
      #
    

  


  

      
HI,

I'm following this discussion with interest, for the following reason.  
There are more than a dozen packages that I have written and still 
maintain.  Most of them were started while I was at M.D. Anderson ,  
They were served from a highly non-mainstream repository hosted there, 
with the code managed in a local Subversion repository. behind their 
firewall   Since moving to Ohio State, I transferred the code to 
R-Forge.  (If you want to figure out what the packages are and do, 
search for "OOMPA".)  So, it's still in a "non-mainstream" repository, 
but it's (to continue the metaphor) at least on a bigger tributary than 
it used to be.

Many of the packages are written to be compatible with some of the core 
BioConductor classes, which means that they import Biobase.

But all of the functionality is available without using BioConductor 
(provided the user is willing to assemble the data into the correct set 
of matrices).

I've been thinking about submitting it to either CRAN or BioConductor.  
Which makes more sense?

Best,
   Kevin

        
On 3/4/2015 4:27 PM, Laurent Gatto wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        
---
This email has been checked for viruses by Avast antivirus software.

  
  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
On Wed, Mar 4, 2015 at 1:27 PM, Laurent Gatto <lg390 at cam.ac.uk> wrote:

            

      
      
      
    

        
Correct, that's my interpretation too. I asked Kurt about this when
they announced it last year:

            

      
      
      
    

        
which implies you don't have to add it, because (from
http://cran.r-project.org/web/packages/policies.html) "Packages on
which a CRAN package depends **should be available from a mainstream
repository**: if any mentioned in ?Suggests? or ?Enhances? fields are
**not from such a repository**, where to obtain them at a repository
**should be specified in an ?Additional_repositories? field** of the
DESCRIPTION file (as a comma-separated list of repository URLs) or for
other means of access, described in the ?Description? field."'

Also, I have a few CRAN packages that relies on both Bioc and R-Forge
packages (e.g. http://cran.r-project.org/web/packages/aroma.core/) and
CRAN does not complain that I only specify:

Additional_repositories: http://r-forge.r-project.org

which is inline with my above interpretation.

BTW, in case someone cut'n'paste from here: 'Additional_repositories'
(not 'Additional_repository').

            

      
      
      
    

        
My interpretation on this is that by defining "mainstream" and adding
'Additional_repositories' it will as first move allow CRAN to automate
the installation of packages on the CRAN farm as far as possible
(except for the fallback to with manual instructions in the
'Description' field).  Hopefully, the next move is that automated
repository-lookup/forwarding becomes part of the default installation
machinery.  For CRAN and Bioc that shouldn't be too hard, particularly
since a package can no longer exist on both.  It's a bit more try to
decide what to install if a package is on CRAN but an "under
construction" version is available on R-Forge; I would go with CRAN
only for those cases, but it could become confusing, cf. "install from
source instead of old binary?"

            

      
      
      
    

        
It feels like that should be possible to solve programmatically, as
long as the metadata is there (see my previous reply).

Cheers,

Henrik

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Vincent Carey
    

    

      
      #
    

  


  

      
On Wed, Mar 4, 2015 at 5:21 PM, Kevin Coombes <kevin.r.coombes at gmail.com>
wrote:

            

      
      
      
    

        
Sometime we should write up comments to help with decisionmaking in this
domain.  In my view the main
difference at this time is the simultaneous management of release and devel
streams in Bioc.  This leads to
a bit of additional complexity for the developer but it permits aggressive
experimentation in the devel branch
that will add mileage from those using the bleeding edge, while not
affecting users of the release branch.

There may be some differences in the continuous integration interface and
the task view discovery support.
There are probably other differences that others should chime in on.

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Dan Tenenbaum
    

    

      
      #
    

  


  

      
----- Original Message -----

            

      
      
      
    

        
If your package has to do with the analysis and comprehension of high-throughput genomic data, then Bioconductor is probably the first place people will look for it. If it does not, then it belongs on CRAN.

Dan