ensure_dir() should also check for ENOTEMPTY

[BorisZZZ]

Environment

• pip version:
  pip 19.0.3

• Python version:
  python 3.7

• OS:
  'python:3.7-alpine3.9' docker image (docker-ce 17.9) running on Ubuntu 18.04.2 LTS in WSL (Windows)

Description
pip install pipenv fails with the following error:

Could not install packages due to an EnvironmentError: [Errno 39] Directory not empty: '/tmp/pip-install-wx86kab7/pipenv/pipenv'

How to Reproduce

1. Set up environment as described above (alpine3.9, on docker-ce 17.9, running on Ubuntu in WSL). and run the command.

2. apk --update add --virtual build-dependencies libffi-dev openssl-dev build-base

3. pip install --upgrade pip

4. pip install pipenv

Output

Could not install packages due to an EnvironmentError: [Errno 39] Directory not empty: '/tmp/pip-install-wx86kab7/pipenv/pipenv'

Investigation
Compared strace results of a successful run (on a different env) vs the failed run.
On a successful run, the mkdir command is continually executed with /tmp/pip-install-<hash>/pipenv/pipenv as an argument and fails with an EEXIST error. However, on the failed run the same command fails with an ENOTEMPT error. This has to do with the environment itself (maybe docker/windows related), as the same difference is observed when simply performing mkdir from a shell.

[uranusjr]

Can you provide an example with only mkdir in play instead of pip? I am having trouble believing makedirs could fail with ENOTEMPTY. (And if it does, this seems like a bug in WSL.)

[BorisZZZ]

In an environment such as the one described above (python:3.7-alpine3.9 docker image, docker-ce 17.9, running on Ubuntu 18.04.2 LTS in WSL - see https://medium.com/devopslinks/docker-running-seamlessly-in-windows-subsystem-linux-6ef8412377aa for possible setup), running mkdir on a path that represents a directory that already exists either:

1. succeeds if the directory is empty, or
2. fails with ENOTEMPTY error.

[uranusjr]

So, to summarise, this happens when you install Docker in WSL, and run mkdir in it? It would be more suitable to report this to WSL if that’s the case.

[chrahunt]

It looks like this change could be related and may help reproducing.