15
$\begingroup$

What are the advantages of having Bioconductor, for the bioinformatics community?

I've read the 'About' section and skimmed the paper, but still cannot really answer this.

I understand Bioconductor is released twice a year (unlike R), but if I want to use the latest version of a package, I'll have to use the dev version anyway. A stamp of approval could be achieved much easier with a tag or something, so it sounds just like an extra (and unnecessary) layer to maintain.

Related to this, what are the advantages as a developer to have your package accepted into Bioconductor?

$\endgroup$
  • $\begingroup$ +1 … the idea of having centralised repositories is becoming more and more out of fashion because there’s no clear evidence for its supposed benefits. $\endgroup$ – Konrad Rudolph Jun 11 '17 at 15:27
  • 2
    $\begingroup$ Is the question "What are the advantages of having Bioconductor over CRAN?" or "What are the advantages of having any kind of central repository? - lets take Bioconductor as example"? $\endgroup$ – Kamil S Jaron Jun 11 '17 at 21:42
  • 1
    $\begingroup$ @KamilSJaron My question is neither -- or both: What are the advantages of having Bioconductor, or any similar central repository, over CRAN? If anything, the focus is on having any R repo for bioinformatics, as opposed to a website, where the approved packages are listed. $\endgroup$ – Peter Jun 12 '17 at 9:52
15
$\begingroup$

Benefits of central repository for Community

Having a central repository for packages is very useful. For couple of reasons:

  • It makes very easy to resolve dependencies. Installing all the dependencies manually would be exhausting but also dangerous (point 2).
  • Package compatibility! If I install package with dependencies, I would like to be sure that I install correct versions of all the dependencies.
  • Reliability thanks to unified and integrated testing. Bioconductor is trying really hard to force developers to write good test, they also have people manually testing submitted packages. They also remove packages that are not maintained. Packages in Bioconductor are (reasonably) reliable.

In the end, installing dev versions of R packages is in my opinion very bad practise for reproducible science. If developers delete GitHub repo, commit hash you have used won't be enough to get the code.

Benefits of central repository for developers

I forgot about the advantages for you as developer to submit your package to Bioconductor:

  1. Your package will be more visible
  2. users will have a guarantee that your code was checked by third person
  3. Your package will be for users easier to install
  4. Your package will be forced to use standardized vignettes, version tags and tests -> will be more accessible by community to build on your code

Bioconductor specific advantages over CRAN

I see the big advantage in the community support page, provided by Bioconductor. @Llopis' comprehensive elaboration.

$\endgroup$
  • 1
    $\begingroup$ I think you're missing: data packages. CRAN has quite strict file size limits (5 MB) and biology needs e.g. genomes. Your points 1 and 3 are debatable (1: bio yes, otherwise no; 3: I'd argue it's harder, needs an external installer). $\endgroup$ – Michael Schubert Jun 12 '17 at 17:41
  • $\begingroup$ You do not want write package with genomic data stored inside anyway - we rather write packages for pulling data from databases. But point taken. Now I see I made a smart move, when I numbered both overall advantages for community and advantages for developers. $\endgroup$ – Kamil S Jaron Jun 12 '17 at 18:10
  • $\begingroup$ Ok, I turned upper numbers to bullet points and I made clear that I am speaking about central repositories in general. $\endgroup$ – Kamil S Jaron Jun 12 '17 at 18:32
  • 1
    $\begingroup$ @KamilSJaron Regarding data packages, they’re an established best practice in Bioconductor (see BSGenome) though I tend to agree: I dislike how the Bioconductor data packages clutter my disk. $\endgroup$ – Konrad Rudolph Jun 13 '17 at 10:16
9
$\begingroup$

Here is a list of the advantages of having Bioconductor for the bioinformatic community:

  • Outreach: You have a repository for the field, in that language.

Some packages related to bioinformatics (in R) are distributed through personal repositories, CRAN, github, bitbucket, sourceforge, but they are less used and harder to find.
There are such efforts in other languages too: Biopython, Bioperl, Biojava, ...
Also is harder to find the repositories related to a subject in CRAN, you don't have the BiocViews, the equivalent is optional and not usually filled, which is quite useful when looking for a method.

  • Quality: In Bioconductor each package is tested in Linux, Windows, and iOS, to make sure it works in all major operative systems (with all the dependencies).

In some rare cases like this one, a packages is not supported for certain platform, but you can known it by checking the build report.
You are required to provide a vignette and examples in every exported element (and the vignette, examples and tests should pass). You are required to be able to install the package with stricter quality than CRAN, because there is a manual review (They pointed out a comment in one of my functions!).
They also provide docker images of the base packages. You don't need to install the latest R version to use the Bioconductor! But developers do so (at least when checked by Bioconductor servers) to ensure that the package will keep working in next R release.

  • Reusing: Bioconductor provides the basic elements to a big number of applications.

For example the summarizedExperiment class is provided so that any package that needs a similar object can (should) use it. Or GSEABase is the base package to deal with GSEA enrichment analysis, providing functions, methods and classes for gene sets, and collections, making easier for anyone to create their own GSE analysis.
It is easier to build upon the work of others if you know you are following the same quality standards.

  • Support: To support Q&A is mandatory, the package maintainer must be registered in the webpage.

While in CRAN usually the support is given by each package in its own way, in Bioconductor you can directly reach the maintainer and the users by posting in the same central place.

$\endgroup$
  • $\begingroup$ Did you try submitting to CRAN? As far as I understand they also run tests, and perform a package review; some people even complain that CRAN people are too pedantic. $\endgroup$ – Iakov Davydov Jun 11 '17 at 10:44
  • $\begingroup$ The OP is about "why central repository", the CRAN / Bioconductor holy was I started in the answer. $\endgroup$ – Kamil S Jaron Jun 11 '17 at 21:48
2
$\begingroup$

Regarding what the advantage is to you as a developer of having a bioconductor package rather than using CRAN:

  1. There's a hierarchy of package quality, with bioconductor on the top (followed by CRAN and then "random github repos"). While there are many excellent CRAN packages, the average bioconductor package is better tested and documented. So if I as a user have two different packages that I can use and one is on bioconductor and the other CRAN, then I use the bioconductor package.
  2. Higher visibility. Since bioconductor packages are held in higher regard, they also become more visible. Further, the different "views" (e.g., "Alternative Splicing" and "Transcription") make it convenient to find relevant packages. You can always search CRAN, but allowing tagging like this aids in discovery.
$\endgroup$
  • $\begingroup$ I have been using a lot of packages from both CRAN and Bioconductor, I haven't noticed that CRAN packages are worse in any sense. I even noticed that documentation of some packages from Bioconductor was worse (at least that was the state several years ago). $\endgroup$ – Iakov Davydov Jun 11 '17 at 10:16
  • $\begingroup$ You've had nice luck with CRAN packages then. $\endgroup$ – Devon Ryan Jun 11 '17 at 10:17
  • $\begingroup$ Pretty sure the quality hierarchy is wrong: if a package is maintained on Github, odds are its quality is in fact superior than that of the average CRAN or Bioconductor package. This might soon change once Github becomes more widespread amongst beginning R programmers but I’m pretty certain it currently still holds. $\endgroup$ – Konrad Rudolph Jun 11 '17 at 15:28
  • 1
    $\begingroup$ @DevonRyan My mistake, I meant "is hosted on". There's a risk it's unmaintained (but the same is true for centralised repositories) but the odds of quality given location = Github are still high. I'll grant that it's possible that the variance of quality is also higher on Github, but even for that I'm not sure. $\endgroup$ – Konrad Rudolph Jun 11 '17 at 19:22
  • 1
    $\begingroup$ @KonradRudolph the most of Bioconductor packages are maintained on GitHub (at least the most of I have used). I have GitHub R package as well, but it is definitely not passing any tests, it is working on my computer in the way that I use it. No being on GitHub is not any sign of quality... but true, if the package is only there, nobody will know about it, so there won't be any bug reports. $\endgroup$ – Kamil S Jaron Jun 11 '17 at 21:45
2
$\begingroup$

The most important reason is that Bioconductor has growing set of common data structures and base packages. If package X and package Y needs to work with the same type of data, having a common data structure in the core Bioconductor package Z makes our lives so much easier. I could do something in package X, take out the results and keep working on my data with package Y. This works because I'm using versions of package X and Y that are compatible with the data structure defined in package Z. The Bioconductor team makes sure that all packages use the common data structures and already existing packages where possible, so that we're all on the same page and so that people don't reinvent the wheel again and again.

Also, there's a sophisticated process around getting your package accepted to Bioconductor. This ensures that packages use data structures and functions already available in other Bioconductor packages (where reasonable), it ensures that packages are well written, that they have good documentation, and that they are well tested.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.