Added Docker files for development environment.

[airvzxf]

📝 Description

This is a proposal to generate a development environment to easily configure and launch TARDIS with Conda and Mamba. This development environment downloads the repositories as “data reference” and “atomic data”. Beyond this, you can run TARDIS, unit tests with PyTest and benchmarks with ASV.

Note: I keep this pull request as a draft because I believe that it needs to be discussed with the owners and maintainers of TARDIS.

Type: 🚀 feature

All the information is in this YouTube video with the walkthrough about the different flavors of the development environment, its usages and cons.

I tried to install all the requirements, and I noticed that it is quite of difficult and some packages were installed as Conda. I would rather not mix my personal environment with the TARDIS development environment. For this reason, I created a series of Docker processes to have 3 types of environment: one for static code in the container, another fragmented (mixed) and the total live which means use your local computer (host) to take and store files.

To see more references, check the file: Dockerfile-benchmarks.bash. Furthermore, one video is better thatn ten thousand of words; I created a YouTube video explaining this development environment usage.

Docker

Static

Pros:

• Easy setup.
• Straight usage.
• Isolate the results and publish them for ASV.

Cons:

• The modifications in local (host) are not reflected in the containers. Except if it is built again.

Fragmented

Pros:

• It takes the live source code.
• The “.asv/results” and “.asv/html” are created in the code folder (live).
• The folders “pkg” and “.asv/env”. It is created in the “image” and dynamically used in the container.

Cons:

• If you want to test or introduce changes to “asv.conf.json”, it is not reflected in the code folder; you need to copy and modify this file again.
• With more than one container, the results and publishes for ASV are shared in the same place (the live code folder).

Live

Pros:

• It takes the live source code.
• Change “asv.conf.json” at any moment and reflect it in the containers.

Cons:

• The folders “pkg” and “.asv/env” are created in the code folder (live). They have a gigabyte size.
• With more than one container, the ASV folders will be shared in the same place (the live code folder).

📌 Resources

N/A

🚦 Testing

How did you test these changes?

• Testing pipeline
• Other method: Benchmarks.
• My changes can't be tested (explain why)

☑️ Checklist

• I requested two reviewers for this pull request
• I updated the documentation according to my changes
• I built the documentation by applying the build_docs label

Note: If you are not allowed to perform any of these actions, ping (@) a contributor.

[tardis-bot]

*beep* *bop*

Hi, human.

I'm the @tardis-bot and couldn't find your records in my database. I think we don't know each other, or you changed your credentials recently.

Please add your name and email to .mailmap in your current branch and push the changes to this pull request.

In case you need to map an existing alias, follow this example.