* Dockerfile build: let Poetry create a venv (otherwise downstream builds using this image fail with weird self-installation errors)

* S3 pulling: catch urllib exceptions (when the cloud storage isn't available) so that the calling object manager isn't left in an inconsistent state.

Author: mildbyte

Dockerfile

@@ -7,7 +7,7 @@ RUN curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poet
 RUN mkdir /splitgraph
 COPY . /splitgraph
 
-RUN $HOME/.poetry/bin/poetry config settings.virtualenvs.create false
+RUN $HOME/.poetry/bin/poetry config settings.virtualenvs.create true
 RUN cd /splitgraph && $HOME/.poetry/bin/poetry install --no-dev
 
 # The pip-wheel-metadata is supposed to be temporary. For downstream image builds, Poetry tries to reinstall Splitgraph
@@ -18,4 +18,4 @@ RUN cd /splitgraph && $HOME/.poetry/bin/poetry install --no-dev
 # See https://github.com/pypa/pip/issues/6213
 RUN rm /splitgraph/pip-wheel-metadata -rf
 
-CMD sgr
+CMD sgr

splitgraph/hooks/s3.py

@@ -5,6 +5,7 @@
 import tempfile
 from concurrent.futures import ThreadPoolExecutor
 
+import urllib3
 from minio import Minio
 from minio.error import (BucketAlreadyOwnedByYou,
                          BucketAlreadyExists, MinioError)
@@ -107,6 +108,10 @@ def _do_download(obj_id_url):
             except MinioError:
                 logging.exception("Error downloading object %s", object_id)
                 return
+            except urllib3.exceptions.RequestError:
+                # Some connection errors aren't caught by MinioError
+                logging.exception("URLLib error downloading object %s", object_id)
+                return
             engine = get_engine()
             engine.load_object(SPLITGRAPH_META_SCHEMA, object_id, object_response)