removing bpython removed requests, which poetry needs

> <new venv>
> pip install poetry
> poetry new <project>
> cd <project>
> poetry add --dev bpython
Using version ^0.17.1 for bpython

Updating dependencies
Resolving dependencies............


Package operations: 8 installs, 0 updates, 0 removals

Writing lock file

  - Installing cryptography (2.2.2)
  - Installing curtsies (0.3.0)
  - Installing greenlet (0.4.13)
  - Installing ndg-httpsclient (0.4.4)
  - Installing pyasn1 (0.4.2)
  - Installing pygments (2.2.0)
  - Installing pyopenssl (17.5.0)
  - Installing bpython (0.17.1)
> poetry remove --dev bpython
Updating dependencies
Resolving dependencies....


Package operations: 0 installs, 0 updates, 13 removals

Writing lock file

  - Removing bpython (0.17.1)
  - Removing certifi (2018.1.18)
  - Removing chardet (3.0.4)
  - Removing cryptography (2.2.2)
  - Removing curtsies (0.3.0)
  - Removing greenlet (0.4.13)
  - Removing idna (2.6)
  - Removing ndg-httpsclient (0.4.4)
  - Removing pyasn1 (0.4.2)
  - Removing pygments (2.2.0)
  - Removing pyopenssl (17.5.0)
  - Removing requests (2.18.4)
  - Removing urllib3 (1.22)
> poetry add bpython


  [ModuleNotFoundError]
  No module named 'requests'


add [-D|--dev] [--optional] [--dry-run] [--] <name> (<name>)...

>

You can see that poetry removes more than it installed for bpython. In particular, it removed requests, which it needs to operate.

[sdispater]

Oh. I see what the problem is!

You should not install poetry in your virtualenv but globally. poetry is not intended to be installed inside the virtualenv you want to work on.

[toejough]

My suggestion would be for poetry to detect that it’s installed in the same env it’s managing and take its own dependencies into consideration when managing that environment. Poetry could conceivably do this by detecting that it’s locally installed, and if it doesn’t have a record of its deps, reinstall itself to gain that record, then clean up anything left over.

It doesn’t have to be done that way. It doesn’t have to be done at all. If it’s not done at all, I’d at least like to see some text in the resulting error that guesses that maybe this unsupported installation method is to blame.

Generally, my contention is that it should be more difficult to use poetry to break poetry’s own dependencies, particularly when it’s billed as a smarter dependency management solution. I’ll understand/respect if @sdispater wants to close this, or if it just gets low priority, but I still think local installation is a reasonable case to handle.