Author Archives: Stian

Developing a Bioconductor package with RStudio and Docker

If you’re going to develop a Bioconductor package you’ll soon discover that your package has to work on both the development version and the release version of Bioconductor. This means that your package has to build against two different versions of R. Which means you need two different R versions on your own machine to develop your package. This can be done, but not nicely. So what can we do?

Docker solves this problem for us: Instead of having to install R on your own system, you can use an existing Docker image with the appropriate R version already installed. Bioconductor makes our job even easier, as they have ready-made Docker images for both the development and the release version of Bioconductor. And to top that off, they have Docker images based the RStudio Docker images, which gives us our development environment of choice right in our browser. Let’s take a look at how these images work.

  1. Run docker run -it -p 8787:8787 bioconductor/devel_core2. This will start a container from the Docker image bioconductor/devel_core2, and setup the port 8787 on your machine to be routed to port 8787 inside the Docker container.
  2. Open http://localhost:8787/ in your browser. This will open the web frontend for RStudio which is running in the Docker container. You might have to login: The default username/password should be rstudio/rstudio.

As you can see, I’m presented with development version of R. A collection of Bioconductor packages have already been installed in this Docker image for our convenience. That was easy, wasn’t it? Let’s try the release version next:

  1. This time run docker run -it -p 8787:8787 bioconductor/release_core2. This will start a container from the Docker image bioconductor/release_core2, and again setup the port 8787 on your machine to be routed to port 8787 inside the Docker container.
  2. Open http://localhost:8787/ in your browser.

Look at that! Only a few keystrokes and we have the release version of R with Bioconductor packages ready to go right there in our browser.

This is nice as it is, but what if you want to work on your existing scripts or existing package? Let me show you how I usually work with these Docker images when developing chimeraviz:

  1. (This first step is optional. Just use your own R code if you have something already.) Clone the chimeraviz repository to somewhere on your computer: git clone https://github.com/stianlagstad/chimeraviz
  2. Go to the folder where you have your R code. The location of chimeraviz on my system is /home/stian/dev/chimeraviz, so I’ll go there.
  3. Run docker run -it -p 8787:8787 -v /home/stian/dev/chimeraviz/:/chimeraviz bioconductor/release_core2. This will start a Docker container from the bioconductor/release_core2 image as before, bit it will also create a link between the folder /home/stian/dev/chimeraviz on my system and the folder /chimeraviz inside the Docker container. The result? My code is available inside the container.
  4. Open http://localhost:8787 in your browser.
  5. Execute setwd("/chimeraviz") in RStudio.
  6. Down to the right inside RStudio, press “More” and then “Go to working directory”:

With these steps done, you’re ready to start fixing bugs in chimeraviz (of which there are none, surely!). When you’re done, you can execute devtools::check() to make sure everything is still working nicely, and then submit a pull request. 🙂

This is how I’m currently working when doing changes in chimeraviz. I do changes on the master branch, which has the development version, within the bioconductor/release_core2 Docker image. For the current release version, I checkout the RELEASE_3_6 branch, and do changes inside the bioconductor/devel_core2 Docker image. I don’t need R installed on my own system at all. If I’m lazy, I might even skip the devtools::check() step and let Travis check the build for me.

Hope this helps someone! Please do leave a comment if you have any suggestions that can improve the way I work with R.

Setting up a continuous integration pipeline for an R Bioconductor package with Travis

I’ve been thinking about setting up a continuous integration pipeline for the chimeraviz package for a while. Two things held me back:

  1. I thought it would be a hassle to make work.
  2. I was the only contributor, so I could just build it on my own machine.

Since I’ve recently received several pull requests to chimeraviz, the first point is no longer true, so I thought I’d finally challenge the second point.

What is Travis?

Travis CI is a continuous integration service used to build and test open source projects hosted on GitHub. Setting up R projects with Travis used to be a hassle, but now Travis has native support for the R language: https://docs.travis-ci.com/user/languages/r/. The best thing about it? It’s free when your repository is public. Since I have a GitHub repository for chimeraviz in addition to the Bioconductor git repository, Travis is a great fit.

Using Travis to build chimeraviz

To enable Travis builds for chimeraviz, I first had to sign in on Travis using my GitHub account. Once signed in, I simply had to flick a switch to enable Travis builds for my chimeraviz repository.

For Travis to know how to build chimeraviz, I had to create a .travis.yml configuration file. The getting started site for R had a few pointers, and after a few tries I got it working with this:

# R for travis: see documentation at https://docs.travis-ci.com/user/languages/r
language: r
sudo: false
cache: packages

r:
  - bioc-devel

warnings_are_errors: true

script:
  - Rscript -e "library(devtools); devtools::check()"

notifications:
  email:
    on_success: always
    on_failure: always

Note this part:

r:
  - bioc-devel

Here I specify which version of R should be used for my build. Luckily, Travis has R versions including Bioconductor for both its release (bioc-release) and development (bioc-devel) versions so I don’t have to do anything special to get Bioconductor packages installed.

With this in place, contributors submitting pull requests to chimeraviz will get feedback on whether their changes introduce any problems with the build:

The next step is to introduce the use of a code coverage tool. I’ll update this post with the additional information when I get that working as well.

UPDATE: Adding code coverage report with codecov.io was very easy – I just had to add this to the .travis.yml file:

script:
  - Rscript -e "library(devtools); devtools::check()"

r_github_packages:
  - r-lib/covr

The complete .travis.yml then looks like this:

# R for travis: see documentation at https://docs.travis-ci.com/user/languages/r
language: r
sudo: false
cache: packages

r:
  - bioc-devel

warnings_are_errors: true

script:
  - Rscript -e "library(devtools); devtools::check()"

r_github_packages:
  - r-lib/covr

after_success:
  - Rscript -e 'covr::codecov()'

notifications:
  email:
    on_success: always
    on_failure: always

And I’m able to show the code coverage on the README of the package:

As well as have these checks run automagically whenever someone submits a pull request:

Running linux on Acer Aspire V3-571G

UPDATE October 15th: I’m back to using Ubuntu due to the touchpad issue with Linux Mint. I still have no solution for the multiple screen problems or for the video problems with Ubuntu.


Running linux on my Acer Aspire V3-571G laptop turned out to be harder than I thought it would be. I don’t think I’ve settled on a distro yet, but here are my experiences so far:

Ubuntu

Being the most popular distro (lingo for linux distribution), I tried Ubuntu first. It seemed to work well enough out of the box, but I had problems using multiple displays. I like to hook my laptop up to a second screen but for some reason only half of the screen would show. I spent hours and hours researching the problem and solutions to it. The fact that the laptop has two graphic cards, one from Intel and one from NVIDIA, leads to a ton of problems. Supposedly, the new nvidida prime drivers should make life easier, but they didn’t work for me.

I also have problems playing videos. Playing any video will in most cases cause the laptop to freeze.

Kubuntu

Kubuntu is a variant of Ubuntu with another type of desktop. It never worked for me at all. I could log in, but the desktop wouldn’t launch.

Lubuntu

Lubuntu is a very light weight version of Ubuntu, using the small desktop LXDE. It worked well. It was very fast, and easily customizable. It’s the distro I still use on an old 13″ netbook I have. The reason I didn’t stick with Lubuntu is that it is indeed very lightweight. A lot of features I’m used to having weren’t there, and though I guess I could’ve spent some time trying other window managers and whatnot, I went on to try something else.

Arch Linux

No. Too close to the metal for me. I’m ashamed to say that I didn’t even manage to install it correctly. It looks like several people are running Arch with this laptop though, so don’t be discouraged by my impatience.

Linux Mint

I like Linux MInt with the Cinnamon desktop. It’s the distro I’m using right now, while writing this post. The only issue, and it might actually be reason enough to try another distro, is that my touchpad stopped working after the first reboot. The drivers won’t load. I can point and click with it, but scrolling won’t work. So far using an external mouse has gotten me through the day, but if I can’t find a solution to this problem then I’ll try something else.

One thing that annoyed me at first is that I can’t log in to wireless networks that require a username and password by clicking on the network in the list of available networks. It’s not an issue though, when I discovered that manually adding the network by connecting to a “hidden network” worked.

I’ve also tried linux mint with the MATE and Xfce desktops without much luck.


 

I’ll keep updating this post as I try new linux distros on my Acer Aspire V3-571G laptop.