Poetry: Poetry Detects All Virtualenvs as Invalid in MSYS2

[danyeaw]

• [X] I am on the latest Poetry version.
• [X] I have searched the issues of this repo and believe that this is not a duplicate.
• [X] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Windows 10 in MSYS2 MINGW64 shell
• Poetry version: 1.0.2 through 1.1.0a1
• Link of a Gist with the contents of your pyproject.toml file: https://github.com/gaphor/gaphor/blob/master/pyproject.toml

Issue

poetry install always fails in MSYS2 with poetry > 1.0.0. This is a regression that was added in version 1.0.1 in PR #1797, since all previous versions including 1.0.0 didn't have this issue. I am using MSYS2 so that I can build my GTK app in Windows.

Poetry has never worked to create virtualenvs in MSYS2, and that is fine since I am OK managing my own virtualenv. The settings are:

virtualenvs.in-project = true
virtualenvs.create = false

Poetry added functionality to check whether the venv is valid, and even though I have a venv that is working fine, poetry detects it as broken. Ironically, poetry then breaks the venv by trying to remove it and recreate it which fails.

I would expect that poetry's behavior would be to turn off virtualenv functionality when virtualenvs.create = false. That options means to me that I don't want poetry to manage virtualenvs, so it doesn't make sense to me why poetry would try to check if the virtualenv is valid, or try to recreate a virtualenv.

$ poetry install -vvv
The virtual environment found in C:\tools\msys64\home\DYEAW\gaphor\.venv seems to be broken.
Recreating virtualenv gaphor in C:\tools\msys64\home\DYEAW\gaphor\.venv

[PermissionError]
[WinError 5] Access is denied: 'C:\\tools\\msys64\\home\\DYEAW\\gaphor\\.venv\\bin\\poetry.exe'

Traceback (most recent call last):
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\clikit\console_application.py", line 131, in run
    status_code = command.handle(parsed_args, io)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\clikit\api\command\command.py", line 120, in handle
    status_code = self._do_handle(args, io)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\clikit\api\command\command.py", line 163, in _do_handle
    self._dispatcher.dispatch(PRE_HANDLE, event)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\clikit\api\event\event_dispatcher.py", line 22, in dispatch
    self._do_dispatch(listeners, event_name, event)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\clikit\api\event\event_dispatcher.py", line 89, in _do_dispatch
    listener(event, event_name, self)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\poetry\console\config\application_config.py", line 88, in set_env
    env = env_manager.create_venv(io)
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\poetry\utils\env.py", line 622, in create_venv
    self.remove_venv(str(venv))
  File "C:/tools/msys64/home/dyeaw/gaphor/.venv/lib/python3.8/site-packages\poetry\utils\env.py", line 681, in remove_venv
    shutil.rmtree(path)
  File "C:/tools/msys64/mingw64/lib/python3.8\shutil.py", line 730, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:/tools/msys64/mingw64/lib/python3.8\shutil.py", line 603, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:/tools/msys64/mingw64/lib/python3.8\shutil.py", line 608, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:/tools/msys64/mingw64/lib/python3.8\shutil.py", line 606, in _rmtree_unsafe
    os.unlink(fullname)

[mpochron]

+1

[danyeaw]

Would an acceptable solution to this be to turn off the virtualenv checks if virtualenvs.create = false? If so, I can submit a PR.

[mpochron]

Yes, turning off virtualenvs worked me.

[danyeaw]

I was able to reproduce this with 1.1.0a1. If one of the core devs could confirm that they think this would be an acceptable solution, I would be happy to submit a PR.

[danyeaw]

I have confirmed that this issue is now resolved in both 1.0.10 and 1.1.0b2. Thanks for the great library ❤️