JOSS Review: Reasoning behind multiple dockerfiles
hechth opened this issue · comments
I had to make some minor adjustments to build the normal Dockerfile on my machine - I just wanted to ask what is the reasoning behind having a Dockerfile that only installs the dependencies and then having one more that uses the tgoelles/pointcloudset_base:latest base image to install the actual tool on top - would you explain the reason for that? To me it seems like it would be a lot easier to just have one Dockerfile which contains the installed package.
Also, the paths in the main Dockerfile seem a bit off - is that due to the automated CI actions and how they transform the paths?
The pointcloudset_base image is used as a devcontainer for VS code which is used for development.
Do you mean the COPY paths? Yes this was necessary for github actions. Both images are generated in the root folder of the project.
Okay - would it be possible to unify them? Because building the image using i.e the VScode extension fails because of the paths :/
Also, the dev container could be switched to the actual Dockerfile if I am not mistaken? Because this way, people can easily see and modify the requirements in case they want to upgrade/downgrade things or use a different base image - I for example had some problems with the miniconda base images and switched to using some more minimalistic ones.
I know that the modifications can also be applied on top of the docker image that is provided - it just seems a bit cumbersome to me to tie everything to the latest docker image that is hosted.
Yes the dev container could use the actual Dockerfile, but than it is not guaranteed that the image is the same for everyone. Also this means that everybody needs to build them on their own machine which is time consuming. In the current solution this is done by github actions at no cost to the individual developer/user.
The base image is always aimed at active developers of the package, therefore there is only the latest version available.
The "release" image is based on the the latest "base" image and has version tags hosted on docker hub. To my understanding this bakes the latest base image into the release.
The goal for this setup was to completely eliminate the need to build any docker image yourself. So I am curios why you choose to do it anyway? Maybe we need to improve the documentation of the docker setup.
Maybe it is possible to just use the release docker image also for development. I have to check. But this might introduce some confusion with 2 different versions of pointcloudset. One inside the container and one locally installed with pip install -e for development.
Fair point - but then I think it would be good to make sure that the individual versions are also reflected in the dockerfile and that multiple versions with proper tags should be available, latest being the one for the release version.
This also fits the versioning and changelog management.
Yes now I got latest and the version tag for pointcloudset_base and the pointcloudset release. I use the explicit version numbers everywhere which is a much safer solution. I also created and activate the "pointcloudset" conda environment in both images and not use "base" anymore.
In addition I included bump2version to make the versioning and changelog management easier.
That all sounds good! Would just be easier if those changes would be posed as a PR to close this issue, now I have to look through the individual commits and see what exactly went where etc. - just for the future :)
I'll have a look and close the issue afterwards!
Ok, yes. I also changed the docker github actions, which are only triggert on the main branch and It thought that this is a quick fix... But now I found out that you can also trigger actions manually and on branches.
@tgoelles Which commands do you use to build the dockerfiles locally?
docker build --rm -f "docker/Dockerfile" -t tgoelles/pointcloudset_base:v0.3.2 "."
and
docker build --rm -f "docker/release.Dockerfile" -t tgoelles/pointcloudset:v0.3.2 "."
JOSS review os over