Search
Question: Bioconductor docker tags and release versions
2
gravatar for Karl Forner
2.5 years ago by
Karl Forner70
Switzerland
Karl Forner70 wrote:

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
 

 

 

 

 

 

ADD COMMENTlink modified 2.1 years ago • written 2.5 years ago by Karl Forner70
1
gravatar for Dan Tenenbaum
2.4 years ago by
Dan Tenenbaum ♦♦ 8.2k
United States
Dan Tenenbaum ♦♦ 8.2k wrote:

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.

 

ADD COMMENTlink written 2.4 years ago by Dan Tenenbaum ♦♦ 8.2k
0
gravatar for Dan Tenenbaum
2.5 years ago by
Dan Tenenbaum ♦♦ 8.2k
United States
Dan Tenenbaum ♦♦ 8.2k wrote:

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. 

ADD COMMENTlink written 2.5 years ago by Dan Tenenbaum ♦♦ 8.2k
0
gravatar for Karl Forner
2.4 years ago by
Karl Forner70
Switzerland
Karl Forner70 wrote:

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).

 

 

ADD COMMENTlink written 2.4 years ago by Karl Forner70
0
gravatar for Dan Tenenbaum
2.4 years ago by
Dan Tenenbaum ♦♦ 8.2k
United States
Dan Tenenbaum ♦♦ 8.2k wrote:

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.

 

ADD COMMENTlink written 2.4 years ago by Dan Tenenbaum ♦♦ 8.2k

Yes, indeed that could be extremely useful !

ADD REPLYlink written 2.4 years ago by Karl Forner70
0
gravatar for Karl Forner
2.1 years ago by
Karl Forner70
Switzerland
Karl Forner70 wrote:

Great !

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

Thanks,

Karl

ADD COMMENTlink written 2.1 years ago by Karl Forner70

The other suggestions made in this thread have not yet been implemented.

ADD REPLYlink written 2.1 years ago by Dan Tenenbaum ♦♦ 8.2k

Is it planned ? I mean do you intend to implement them ?

best,

ADD REPLYlink written 2.1 years ago by Karl Forner70

Right now it is just an idea that has been tossed around. We need to examine the feasibility of it, and how large the resulting image would be.

ADD REPLYlink written 2.1 years ago by Dan Tenenbaum ♦♦ 8.2k
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 2.2.0
Traffic: 193 users visited in the last hour