I would also add some notes to not impose the usage of hard path when using containerised software. I've seen a lot of people expecting data to be mapped to a specific directory in the container e.g. /data or /inputs. This is a bad practice because limits the portability of the container and it makes hard to re-use it. Along the same line it should be avoided the use of custom WORKDIR in the container definition.

As general advice the container execution should be transparent, in the meaning the containers software should behave irrespective of the container usage, said in other term, the user should be able to use the containerised software independently the container usage.

Just some thoughts about the first point "One tool, one container".

While this is a good practice to maximise the containers usability and makes perfect sense in some scenarios, like for example the BioContainers project, in other contexts it's a principle to abstract IMO. In real world applications it's need to compose many tools together, just think bwa .. | samtools .. | etc.

In this scenario, having a a tool per container is a limiting factor that prevents that idiom or more in general the use of multiple tools in the same task.

Based on a recent EBI internal conversation about source code authorship in Git repositories - Is our recommendation to add the maintainer label compliant with the new GDPR regulations? Data that will be stored will be:

• Full name
• Email Address

More a question for the Bioinformatics container registries (bio.tools and biocontainers.pro)

It could be argued as a legitimate interest to ask for this information - for the sake of reproducibility, but will we need to comply with the right to be forgotten directive which would mean deleting all maintainer labels of the user even for downstream multi-stage builds.

I'm not assuming the right to be forgotten trumps legitimate interest, but do we have a legitimate reason for processing this information. We could argue "we could keep personal information indefinitely in the public interest. We would need to define why it is in the public interest.

No data should be included in the container.

I have switch the topic to containers and not only docker files because making a lot of sense to include other technologies to create containers.

A container should always distributed along with the Dockerfile/recipe used to create it, for transparency and documentation purpose.

However the availability of the Dockerfile does not guarantee the reproducibility of the container images, and consequently, of the associated data-analyses. When re-creating a container image, one or more software packages can be not more available.

To protect against software decay upload your container images to a public registry such as DockerHub or Quay. Even better, use community a collection such as BioContainers which manage the versioning and the long the archiving of container images.

For maximum reusability and smaller containers.

I think that multi-stage builds [1] actually solve and make most of these recommendation redundant:
https://github.com/ypriverol/containers-rules-manuscript/blob/master/manuscript.adoc#6-reduce-the-size-of-your-container-as-much-as-possible

I consider some of these to be actually harmful, combining multiple RUN commands makes the files hard to read and debug. Since multi-stage builds are actually used to specifically address point 6, I think we should recommend them or at least add them to the list of suggestions

1. https://docs.docker.com/develop/develop-images/multistage-build/#name-your-build-stages

@rajido @susheel @pcm32 @prvst @hroest @bgruening @blankenberg @timosachsenberg @osallou @mr-c @biomadeira and all contributors. I have reviewed the current version of the manuscript and it looks almost ready for the first submission to F1000 to the ELIXIR channel. Please give a last try and let me know. If you are happy with the current version give me a +1 on this issue.

Regards
Yasset

Duplicate @bgruening's todo manuscript.adoc#L130

Need to update manuscript.adoc#L134 too.

See https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

And be prepared to justify where we made different choices

• https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5070597.1/
• http://singularity.lbl.gov/docs-docker#best-practices

This would give a container flexibility during build time(ARG) and runtime(ENV), whilst still being reproducible. Just a thought.

Just an enhancement suggestion to reorder recommendations to support a logical flow of a typical Dockerfile. The idea would be to have a example (Box) for each recommendation and have a final example box that brings every recommendation together at the thirteenth recommendation Provide reproducible builds

New suggested order:

1. Choose base image wisely
   FROM biocontainers/biocontainers:v1.0.0

2. Tool and container versions should be explicit

LABEL base_image="biocontainers:v1.0.0"
LABEL version="3"
LABEL software="Comet"
LABEL software.version="2016012"

3. [Proposal] Add appropriate LABELs to point to software documentation, keywords and tags (Can be merged in existing recommendations)

LABEL about.summary="an open source tandem mass spectrometry sequence database search tool"
LABEL about.home="http://comet-ms.sourceforge.net"
LABEL about.documentation="http://comet-ms.sourceforge.net/parameters/parameters_2016010"
LABEL extra.identifiers.biotools="comet"
LABEL about.tags="Proteomics"

4. Check the license of the software and add Maintainer information

LABEL about.license_file="http://comet-ms.sourceforge.net"
LABEL about.license="SPDX:Apache-2.0"
LABEL maintainer="Felipe da Veiga Leprevost <[email protected]>"

5. [Proposal] Use ARG for build-time and ENV for runtime evironment variables (Can be merged in existing recommendations)

ARG COMMET_VERSION="2016012"
ENV PATH /home/biodocker/bin/Comet:$PATH

6. [Proposal] Add explicit WORKDIR (Can be merged in existing recommendations)
   WORKDIR /data/

7. Reduce the size of your container as much as possible

RUN ZIP=comet_binaries_${COMMET_VERSION}.zip && \
  wget https://github.com/BioDocker/software-archive/releases/download/Comet/$ZIP -O /tmp/$ZIP && \
  unzip /tmp/$ZIP -d /home/biodocker/bin/Comet/ && \
  chmod -R 755 /home/biodocker/bin/Comet/* && \
  rm /tmp/$ZIP

Note the use of build time ARGs in the RUN process

8. Relevant tools and software should be executable and in the PATH

RUN mv /home/biodocker/bin/Comet/comet_binaries_${COMMET_VERSION}/comet.${COMMET_VERSION}.linux.exe /home/biodocker/bin/Comet/comet

9. Document the build files
   TODO: Mention the possibility of interspesing the Dockerfile with # comments

10. Add functional testing logic

11. Avoid using ENTRYPOINT

12. Provide helpful usage message via CMD

13. Provide reproducible builds

14. Make your package or container discoverable

Packaging options:

• (Bio)Conda
• Debian(Med)
• Brew

reference the biocontainers spec https://github.com/BioContainers/specs/blob/master/container-specs.md

Which fields are mandatory?