Extra dependencies set installation fails when done from the plugin

[agatti]

Describe the bug
Extra dependencies set install fails from within PyCharm.

To Reproduce
Steps to reproduce the behavior:

1. Have a project with some extra dependencies set.
2. Click on the installation sidebar icon next to the extra dependency set.
3. Poetry pops up an error window.

Expected behavior
Dependencies set installation should work from within PyCharm too. The same command shown to be executed in the error dialog works when run manually from the console.

Screenshots

Environments (please complete the following information):

• IDE: PyCharm Professional 2021.1.3
• OS: macOS 11.4
• Poetry Version 1.1.7
• Plugin version 1.1.4

Additional context
The pyproject.toml file I am having this issue with can be summed up as such:

[tool.poetry.dependencies]
python = ">=3.8, <3.9"
...
pyside2 = { version = "^5.15", optional = true }

[tool.poetry.extras]
qt = ["pyside2"]

And the same command when ran from the console:

agatti@tardigrade <redacted> % which poetry
/opt/local/bin/poetry
agatti@tardigrade <redacted> % poetry install --extras qt
Installing dependencies from lock file
Warning: The lock file is not up to date with the latest changes in pyproject.toml. You may be getting outdated dependencies. Run update to update them.

Package operations: 2 installs, 0 updates, 0 removals

  • Installing shiboken2 (5.15.2)
  • Installing pyside2 (5.15.2)

Installing the current project: <redacted> (<redacted>)
agatti@tardigrade <redacted> %

[koxudaxi]

@agatti
I think that you should run poetry lock before clicking the button.
Because the action button called poetry install --extras qt and the command install from lock file.

[agatti]

@koxudaxi Just wondering, if it was a matter of locking the project file, then the command line version would not have worked, right? After all it's the exact command being executed with the same parameters, according to the dialog. I didn't lock anything between having the error in PyCharm and having the shell execution command work.

Anyhow, locking the environment beforehand didn't solve the issue - recreating the environment from scratch did.

I'm still not sure on what happened, I guess this can be closed - I can always reopen it if the issue shows up again.