[Bioc-devel] bioc pkgs depending on packages that are only in github?
Tim Triche, Jr.
tim.triche at gmail.com
Sat Nov 8 17:27:59 CET 2014
Re: can of worms: yes it is
Re: don't want to open: well, it's either that or I personally cram some other peoples' packages through BioC approval so that my DMRcate and fixSeq mega patches can stick
So, it's a can of worms alright, and maybe the solution is to get more people to submit to their benevolent BioC overlords. Because BioC is what CRAN and Python and various other competitors / rivals / alternatives could have been, if they'd been disciplined about it from the start. BioC (and maybe glmnet/rsig) is the greatest achievement of R. No sense letting that slip just because it's inconvenient. Bring up the level of the github/rforge/googlecode/etc projects instead.
I started this email agreeing with you but as I thought through it, I changed my mind. The great weakness of python (been using THAT lately) is that package documentation sucks. (Also it's crappy for manipulating BAMs). The BioC standards are IMHO the ultimate counterpoint to this, as is BiocParallel, the AMI, the google genomics R client... Why let something awesome like the BioC codebase slide downhill? Make the other guys raise their standards instead. Over the long run, everybody wins (more citations, more users, higher quality code base, better reproducibility for science & industry)
Just mho. My daughter woke up so I'm out of time to edit this monstrosity :-/
> On Nov 8, 2014, at 8:01 AM, Vincent Carey <stvjc at channing.harvard.edu> wrote:
> our guidelines state
> Packages you depend on must be available via Bioconductor or CRAN; users
> and the automated build system have no way to install packages from other
> with increased utility of devtools/install_github perhaps we can relax this?
> is it a can of worms we don't want to open?
> [[alternative HTML version deleted]]
> Bioc-devel at r-project.org mailing list
More information about the Bioc-devel