Maintainance/docker dev env

[jspaezp]

Adds docker container for usage in development.

Why?

1. Since there are dependencies in the package that are not automatically resolved using conda in M1 macs, an alternative is to use a container for development, where all local test runs occur within the container.

Specification for dev containers:
https://containers.dev/overview

[wfondrie]

I think this is a good addition, but we need to document how to use it, perhaps in the README.

As a side note, I can successfully build the production image by specifying the platform:

docker build --platform linux/amd64 .

[wfondrie]

question: What does this customization do?

[jspaezp]

This is a placeholder for vscode plugins .... can be removed
Nontheless, the whole impact of this PR is reduced by #35

[wfondrie]

question: Have you tried used the version of the JRE that is installed in the production image?

We build on top of the official EncyclopeDIA image, which uses the openjdk:8-jre as their base image. I don't know if the JRE version will work with NextFlow, but it might be worth checking.

[wfondrie]

Here's the EncyclopeDIA Dockerfile: https://bitbucket.org/searleb/encyclopedia/src/master/Dockerfile

[wfondrie]

Is this PR still needed with #35?

[jspaezp]

I really like the concept of this pr but ... since right now I am experiencing a weird issue where the tests occasionally stall. Which I believe could be somehow related to the way that nextflow detects that a spawned process has finished, which might be weird when running docker inside groovy inside python inside docker .... So it think we can leave this in the back burner for a while and just document the patch for MSSTATS on mac.

[jspaezp]

@wfondrie

Is this PR still needed with #35?

It still has a place, but i dont think its worth the effort right now, although i do believe we need to document how to patch the msstats situation in m1 macs ... (because I will forget immediately ...)