-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New item: Use of Docker images #15
Comments
I think is better to reference here and standard community like biocontainers.pro to storage the containers. BioContainers define guidelines for containers creation and also provide an architecture to deploy and find bioinformatics contains. In the same way, we suggested that the data should be in a ProteomeXchange repository. The container should be in Biocontainers. |
This is a very good point! But I guess we should still have an item that says "if you use containers, reference them following these guidelines"? |
I agree with @jgriss that the version number should be made explicit, rather than ":latest". Storage in BioContainers should probably be silver/gold level, whereas just having the container available somewhere should suffice as well. Maybe something like this:
|
The BioContainers guidelines do not allow to have the latest version since two years ago. All containers should contain the proper version.
Having the container in your own namespace only will create more issues because, if the namespace disappears what can you do with the version of the docker file?
I think we remove a lot of complexity saying that if a container is used the container should be deposited in biocontainers. Done |
@ypriverol I agree that we remove complexity but we also exclude quite a few use-cases. Biocontainers are great for packaging single tools. What if a group uses one container to run their whole workflow (this is an example that the nextflow guides showed quite a lot) and also put their custom scripts into that container? The container would never be suitable for biocontainers. The same is btw. also true for IsoProt. Therefore, I prefer @bittremieux suggestion |
The container is fine for biocontainer as far as it fits the guidelines: version, description, title, etc. You can put the custom scripts in the container or a conda package. Multitool containers are also supported since a year ago.
Probably this is an example of why do we need to put the container into biocontainer. My point is, if the container is in your namespace and you delete your namespace, the container will be gone, even if you have the version. If we are creating guidelines for reproducible research and the bioinformatics community already have two community like conda and biocontainers to create guidelines about how to deploy containers, how to build them.. what is the point of avoiding them? You can have your own container during the development process, however when you are in the process of making your publication your containers should be release and properly annotated using the biocontainers guidelines and namespace. This is like saying that the proteomics data can be public in a university FTP, when we have progressed a lot in ProteomeXchange.
|
Hi guys, Based on this discussion and an offline one with @ypriverol I updated my proposal. Since we are the first guideline to target Docker containers as well, I believe that this should be highlighted. Category: ContainersName: If containers are used in the analysis, they should be referenced following, for example, the BioContainers guidelines Name: If containers are used in the analysis, these should be available in a public repository using non-personal namespaces Name: Containers should be available in dedicated repositories such as BioContainers |
Hi guys, I've now added the proposed new items to the document. If you agree I'll close this issue and we will continue the discussion (if needed) on the different items. |
Category: Workflow Software (or new section?)
Name: If containers are used in the analysis, they should be referenced through stable version numbers
Category: "bronze"
Description: If containers, such as Docker or Singularity containers, are used in the analysis
they should be referenced through stable version numbers. This explicitly relates to not
using the ":latest" tag for Docker images as these are bound to change upon new releases
of the software.
Fields: "all"
Name: If containers are used in the analysis, these should be available in a public repository
Category: "silver"
Description: If containers, such as Docker or Singularity containers, are used in the analysis
they should be available through a public repository, such as Docker Hub.
Fields: "all"
Reason
The use of containers becomes increasingly common and is increasingly supported by worfklow systems, such as nextflow
The text was updated successfully, but these errors were encountered: