Poetry creates a broken virtualenv if python3-venv is not installed after running poetry install

The other day I was working on a Dockerfile based on a Debian distro. I noticed that if you only have python, pip and setuptools, when running poetry install, Poetry starts building a Python virtualenv at $HOME/.cache/pypoetry/virtualenvs, but it fails midway because of this error:

Creating virtualenv app-py3.5 in /root/.cache/pypoetry/virtualenvs
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: ['/root/.cache/pypoetry/virtualenvs/app-py3.5/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']

If you happen to install python3-venv afterwards, and do poetry install again, you get this:

Using virtualenv: /root/.cache/pypoetry/virtualenvs/app-py3.5
                                              
[FileNotFoundError]            
[Errno 2] No such file or directory: 'pip'  
                                              
Exception trace:
 /usr/local/lib/python3.5/dist-packages/cleo/application.py in run() at line 94
   status_code = self.do_run(input_, output_)
 /usr/local/lib/python3.5/dist-packages/poetry/console/application.py in do_run() at line 87
   return super(Application, self).do_run(i, o)
 /usr/local/lib/python3.5/dist-packages/cleo/application.py in do_run() at line 197
   status_code = command.run(input_, output_)
 /usr/local/lib/python3.5/dist-packages/poetry/console/commands/command.py in run() at line 72
   return super(BaseCommand, self).run(i, o)
 /usr/local/lib/python3.5/dist-packages/cleo/commands/base_command.py in run() at line 146
   status_code = self.execute(input_, output_)
 /usr/local/lib/python3.5/dist-packages/cleo/commands/command.py in execute() at line 107
   return self.handle()
 /usr/local/lib/python3.5/dist-packages/poetry/console/commands/install.py in handle() at line 34
   self.poetry.pool,
 /usr/local/lib/python3.5/dist-packages/poetry/installation/installer.py in __init__() at line 56
   installed = self._get_installed()
 /usr/local/lib/python3.5/dist-packages/poetry/installation/installer.py in _get_installed() at line 514
   return InstalledRepository.load(self._venv)
 /usr/local/lib/python3.5/dist-packages/poetry/repositories/installed_repository.py in load() at line 17
   freeze_output = venv.run("pip", "freeze")
 /usr/local/lib/python3.5/dist-packages/poetry/utils/venv.py in run() at line 271
   cmd, stderr=subprocess.STDOUT, **kwargs
 /usr/lib/python3.5/subprocess.py in check_output() at line 316
   **kwargs).stdout
 /usr/lib/python3.5/subprocess.py in run() at line 383
   with Popen(*popenargs, **kwargs) as process:
 /usr/lib/python3.5/subprocess.py in __init__() at line 676
   restore_signals, start_new_session)
 /usr/lib/python3.5/subprocess.py in _execute_child() at line 1282
   raise child_exception_type(errno_num, err_msg)

The only way to fix this is to delete the whole directory at $HOME/.cache/pypoetry/virtualenvs/app-py3.5 before running poetry install again. This not only happened to me on a Docker container, I had the same thing happen on a new Ubuntu machine that didn’t have virtualenv installed when I tried using Poetry.

Here is a gist with a Dockerfile and steps on how to reproduce bug.

I will try looking into it, although I’m not sure how Poetry should handle this. Perhaps it should do the ensurepip check in a previous instance?