Small patch to fix docker build in SMQTK IQR playground

[chrismattmann]

Hey @Purg and @wphicks, I couldn't get this to build on my Mac without pinning the matplotlib version. Longer story, there is some incompatibility with versions past 2.2.2.

This patch made the build work for me:

nonas:smqtk_iqr_playground mattmann$ git diff
diff --git a/devops/docker/smqtk_caffe/Dockerfile.cpu.df b/devops/docker/smqtk_caffe/Dockerfile.cpu.df
index faf27d74..e622d0ff 100644
--- a/devops/docker/smqtk_caffe/Dockerfile.cpu.df
+++ b/devops/docker/smqtk_caffe/Dockerfile.cpu.df
@@ -12,7 +12,7 @@ RUN rm /bin/sh \
         libatlas-base-dev libatlas-dev libboost-all-dev libprotobuf-dev \
         protobuf-compiler libgoogle-glog-dev libgflags-dev libhdf5-dev \
  # Python dependencies for pycaffe
- && pip install -U pip numpy scikit-image protobuf \
+ && pip install -U pip numpy matplotlib==2.2.2 scikit-image protobuf \
  # Clean products of ``update``
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*

[chrismattmann]

sorry this is actually for smqtk_caffe. Here is where the issue is described:

NVIDIA-AI-IOT/redtail#91

[Purg]

From that linked issue it sounds like its a pip upgrade issue. Since pip is being upgraded here, maybe separating the pip install -U pip and the other package installs onto two separate lines might be a more appropriate fix than version locking.

[chrismattmann]

yeah I thought that @Purg except if you read more onto the redtail issue, when you try and do a pip upgrade pip it blows up the system pip. They ran into the exact same issue I did, so the more appropriate thing to do unfortunately is the version locking. As it stands right now, it will not build on Ubuntu or Mac, without the above Patch.

[Purg]

So I just poked at this a little and found that the reason a pip install -U pip "blows up" the system pip is that if you invoke the pip command in the same bash terminal (resolves to /usr/bin/pip), you are no longer referring to the newly installed pip version, which is located at /usr/local/bin/pip. If pip is invoked in a different RUN line, pip works as intended because the use of a new shell/bash resolves pip to the file executable file located in /usr/local/bin.

[chrismattmann]

fixed in #379 thanks!