Docker remote interpreter skeletons not copied correctly when image has Python PIP packages

I discovered that my code completion and "intellisense" no longer worked when I was using a specific docker container as a python remote interpreter. After some troubleshooting, I discovered that I had installed a handful of python-pip packages from source. During the step where PyCharm tries to download remote sources and skeletons back to the host, it bombs out with:

.skeletons.PySkeletonGenerator - Failed to download remote sources /usr/local/lib/python2.7/dist-packages/setuptools_scm-1.15.0-py2.7.egg to local directory /home/vagrant/.PyCharm2017.1/system/remote_sources/1234..
...
Caused by: com.intellij.docker.remote.run.runtime.WrappedInternalServerErrorException: com.github.dockerjava.api.exception.InternalServerErrorException:
{"message":"lstat /var/lib/docker/aufs/mnt/asdf.../usr/local/lib/python2.7/dist-packages/setuptools_scm-1.15.0-py2.7.egg/.: not a directory"}

Looks like the skeleton copy process expects everything to be a directory and when it encounters a *.egg *file* it bombs out and stops. This leaves the code completion and such without any knowledge of the Docker container.

However, I am able to still do remote debugging and run pytests through the remote (docker) interpreter.

Steps to reproduce are roughly:
1. Create a Docker image (mine was Debian-based) and as part of the image, install setuptools_scm-1.15.x from source (as root). Probably any package will work that leaves a .egg file in the /usr/local/lib/python2.7/dist-packages/ directory

$ cd /tmp
$ wget https://pypi.python.org/packages/03/6d/aafdd01edd227ee879b691455bf19895091872af7e48192bea1758c82032/setuptools_scm-1.15.6.tar.gz#md5=f17493d53f0d842bb0152f214775640b
$ tar xfz setuptools_scm-*.tar.gz
$ cd setuptools_scm-*; python setup.py install

2. Startup PyCharm 2017.1.x (tested with .1 and .4) and configure a remote interpreter via "Docker" and point to the image
3. After the interpreter is configured and it tries to create skeletons from the container, it'll silently fail.
4. Opening up any python script in your project has lost of angry red squiggles under nearly any module import
5. This can further be seen by a simple python script in the project:

#!/usr/bin/env python

import mock # <<-- Angry red squiggles
import os # <<-- Angry red squiggles
import sys # <<-- Angry red squiggles

print("Hello world!")