Hello,

I am very pleased that you provide docker images of bioconductor, I think this is a huge added value for your users.

I may have missed something, but it seems that they are some missing information in the docker tags.

From what I understood, there is no easy way to get a docker for one specific bioconductor release.

I mean, today, if I get bioconductor/release_base it will be the 3.1 version. But in 6 months it will be probably the 3.2 version. Moreover what if I want to reproduce someone's bug in the 3.0 version ? I suppose it is possible based on dates, but it could get quite cumbersome.

That's why I guess that adding some simple tags such as: v3.1:date and v3.1:latest could prove very useful.

Say that I want to get the (current) latest 3.1 version:

docker run bioconductor/release_base:v3.1

if I want the latest 3.0:

docker run bioconductor/release_base:v3.0

Moreover, why not providing a release_all, containing all packages ?

Thanks,

Karl
 

The version tags are now available. The versions supported now are 3.1 (current release) and 3.2 (current devel). As expected, currently 3.1 only works with containers with "release" in their name and 3.2 only works with containers with "devel" in their name. The other suggestions made in this thread have not yet been implemented.

The version tags are a good idea, I'll see what I can do. 

As for a release_all container, it would be too big. And probably couldn't be built--if you look at the build report it's rare that every single package builds on a given day. And would you want all annotation and experiment data packages as well? That would make it very very big. 

Thanks for your reply.

My use case for the release_all container would be to be sure to have the complete bioconductor platform, canonically installed so that I could build my platform upon it without surprises.

I guess it should not contain the annotation and experiment data packages (except maybe those already in the existing release_xxx containers), since they should be straightforward to install (no system dependency, no compilation).

What might make sense is a release_deps container that has all the system dependencies installed, and then perhaps built on top of that can be another container that has every package which either needs compilation or has a SystemRequirements line in its DESCRIPTION file, assuming that every other package should be straighforward to install.

Great !

What about the docker containing all the packages "which either needs compilation or has a SystemRequirement" ?

Thanks,

Karl