Create a Containerized Dev Environment

[jnormile]

It may be worth considering utilizing Docker to create a containerized dev environment for working on Chasten with. This will allow for added mobility long-term if additional dependencies get added (or removed) in such a way that it breaks local dev environments; rather than have to worry about the entire team (across several different operating systems) patching local environments, changes could be made to a single containerized environment that can be accessed and utilized by the entire team.

While this is a task that's not strictly necessary, given the trouble we've seen getting the team started on just running Chasten, this may be a worthwhile endeavor to prevent team-wide roadblocks like this in the future.

This is a task that would require some outside investigation into Docker and Dockerfiles, and would be a good issue for those interested in acquiring a new skill/technical proficiency!

[gkapfham]

Hi @jnormile, I agree that this would be helpful.

As I mentioned in #39 we might also want to investigate which dependencies are causing us problems and then see if there is a way to implement chasten's features without those dependencies.

With that said, we need to have good documentation about the problems we are facing, as you have already noted in #41.

[AidanNeeson]

Hello @jnormile, I took into consideration your insights and decided to whip up a Dockerfile that fulfills the desires expressed above. This Dockerfile, found in this branch, creates an Ubuntu-based dev environment that allows for running chasten!

It is important to note that I see this as a temporary solution to our teams gripes. Meaning, to me at least, it feels better to not publish a tool that requires Docker Desktop to function. As per comments made in #39 by @gkapfham, it would be super beneficial if we can still manage to figure out ways of setting up chasten on each individual operating system. That being said, if the team is comfortable and they want to adopt this as an approach to run the tool, it still must be debugged, maintained, and managed by the team!

In the mean time, below are the instructions to use the Docker container that allows for running chasten!

Preliminary: Make sure Docker Desktop is installed on your computer!

1) Create a file with the name Dockerfile in the outer chasten directory (reference the branch mentioned above if this is unclear).

2) Open a terminal window and navigate to the chasten directory where the Dockerfile was created.

3) Run the following command to build the container docker build -t chasten . -- this takes about 10 minutes, varying with network connection.

4) Once it is built, utilize docker run to start the container. The command differs depending on OS and terminal. Here are the most popular variations:

• Windows (command prompt) -> docker run --rm -v "%cd%":/root/src -it chasten
• Mac/Ubuntu -> docker run --rm -v $(pwd):/root/src -it chasten
• Windows (powershell) -> docker run --rm -v ${pwd}:/root/src -it chasten

5) Once inside the container, run the command poetry install to install all of the dependencies needed for the Chasten tool.

6) Now you should be able to run Chasten smoothly, but before closing the container, complete the following steps to save the dependency installation from the previous step:

• 6a) Open a new terminal window without closing the one that is currently inside of the container and run docker ps. This will list all of the current active containers on your machine. The two pieces of information needed from this are the CONTAINER ID and IMAGE values, specifically for the container named chasten.

• 6b) Run the command docker commit (your-container-id-goes-here) (your-image-name-goes-here)

7) Now you can close the container with exit whenever you want to leave. To start it up again use the command from step 4. This should bring over all changes made to any source code on your local machine. Keep in mind, Any changes made to dependencies will require you to redo steps 5-6b.

[gkapfham]

Wow! Thanks @AidanNeeson! This is amazing, can someone else in our team test this out and then confirm if it works? If we want to move forward with this Docker contain approach then we need to create a PR very soon. Finally, to move forward the discussion, where do we think that the Dockerfile should be located? Should it be published with the project? Should it be published in a separate repository? Should it be published to DockerHub or some other clearinghouse for Docker containers? Overall, I like this idea! But, we need to think carefully about testing this Dockerfile on all major supported platforms and then thinking about how we will deploy it for regular use by developers. And, this leads me to my last question: is this for developers or for people who are using the tool?

[AidanNeeson]

@gkapfham, I can answer one of these questions, and provide some insight on a few others. Firstly, I built this container with the intention that it will be used purely by developers. Its functionality was designed to mount the container as a volume onto a dev's local directory so that the source code files for chasten can be ran without the hassle of OS specific dependency conflicts. That being said, this container, along with the instructions provided, serves no purpose to people who would use the tool. Some slight tweaks would need to be made to achieve that functionality.

As for where it should be located, I am not entirely sure. My vision was for our development team to use it as a resource, but as stated before, it serves no purpose regarding the tool's functionality itself. So I feel that publishing it with the project is the wrong move. Publishing it to DockerHub also feels wrong since, as mentioned before, the container does not offer anything to people using the tool; another container would need to be made that supports this. In my eyes, the best course would be to store it in a separate repository since its only purpose is for aiding the development team.

Anyone, let me know if my line of thinking makes sense, or if it would be better to store it some place else.

[gkapfham]

Okay, thanks for providing your feedback @AidanNeeson. It seems that we need to discuss this further either here or during an in-person meeting of our team members. Thanks! Anyone else with an insight to share?