Currently, the build will fail if, e.g., the user passes numpy==x.y.z to the PIP_PACKAGESbuild-arg, and numpy==a.b.c was hard-coded to be pip-installed in that step.
The solution would probably be to split to-be-installed packages into an array, find duplicates based on substrings before =, and prioritize to the user's version. That amount of logic shared across images would likely require writing a bash function in a separate file, adding it to the build context for cdl-base, and COPYing it in during the cdl-base build. Unfortunately, there are currently no COPY steps in the current cdl-base build, so this would mean adding an a new layer to the base image and increasing the size of it and all child images.
Difference may be de minimis, but not entirely clear. Will probably end up writing this either way and checking the docker image history for cdl-base images build with and without this addition to decide if it's worth it.
Currently, the build will fail if, e.g., the user passes
numpy==x.y.zto thePIP_PACKAGESbuild-arg, andnumpy==a.b.cwas hard-coded to be pip-installed in that step.The solution would probably be to split to-be-installed packages into an array, find duplicates based on substrings before
=, and prioritize to the user's version. That amount of logic shared across images would likely require writing a bash function in a separate file, adding it to the build context forcdl-base, andCOPYing it in during thecdl-basebuild. Unfortunately, there are currently noCOPYsteps in the currentcdl-basebuild, so this would mean adding an a new layer to the base image and increasing the size of it and all child images.Difference may be de minimis, but not entirely clear. Will probably end up writing this either way and checking the
docker image historyforcdl-baseimages build with and without this addition to decide if it's worth it.