Bioconductor docker tags and release versions
5
2
Entering edit mode
Karl Forner ▴ 70
@karl-forner-2831
Last seen 4.6 years ago
Switzerland

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
 

 

 

 

 

 

docker release • 1.4k views
ADD COMMENT
1
Entering edit mode
Dan Tenenbaum ★ 8.2k
@dan-tenenbaum-4256
Last seen 5 months ago
United States

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 COMMENT
0
Entering edit mode
Dan Tenenbaum ★ 8.2k
@dan-tenenbaum-4256
Last seen 5 months ago
United States

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 COMMENT
0
Entering edit mode
Karl Forner ▴ 70
@karl-forner-2831
Last seen 4.6 years ago
Switzerland

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 COMMENT
0
Entering edit mode
Dan Tenenbaum ★ 8.2k
@dan-tenenbaum-4256
Last seen 5 months ago
United States

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 COMMENT
0
Entering edit mode

Yes, indeed that could be extremely useful !

ADD REPLY
0
Entering edit mode
Karl Forner ▴ 70
@karl-forner-2831
Last seen 4.6 years ago
Switzerland

Great !

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

Thanks,

Karl

ADD COMMENT
0
Entering edit mode

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

ADD REPLY
0
Entering edit mode

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

best,

ADD REPLY
0
Entering edit mode

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 REPLY

Login before adding your answer.

Traffic: 711 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6