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.z
to thePIP_PACKAGES
build-arg
, andnumpy==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 forcdl-base
, andCOPY
ing it in during thecdl-base
build. Unfortunately, there are currently noCOPY
steps in the currentcdl-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
forcdl-base
images build with and without this addition to decide if it's worth it.