removing bpython removed requests, which poetry needs

[toejough]

> <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]

That's why you should use the recommended way of installing poetry and not install it via pip since it is specified that it can mess with you system.

[toejough]

interesting. are you opposed to encoding (and then protecting) poetry's own dependencies, or is that just something that hasn't gotten to the top of the priority queue yet?

[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]

I can totally do that - I was thinking of installing it with pipsi next, actually. I'm curious, though - if I were to get adventurous enough (and make enough time) to put up a PR for protecting poetry's dependencies so that it could be installed in a virtualenv, would you accept that PR, or is not working in the same env you're installing other stuff to a conscious choice that you want to maintain?

I get it if such a thing isn't high priority for you because there's a very workable solution to the situation I encountered, but since you can install it in a virtualenv, I want it to be able to work that way.

[toejough]

also, installing with pipsi worked great.

[sdispater]

Protecting poetry's dependencies would be hard since if, for instance, poetry depends on requests<3.0.0 but one of the dependencies of the current project requires requests>=3.0.0 it would lead to an incompatibility.

That's why it is not recommended to install poetry in the current virtualenv. That's also why using the custom installer is the way to go because this way poetry will vendor its own dependencies and therefore protect them.

[toejough]

I get that it's not recommended, but I don't think it's any worse problem than you encounter in python generally, is it? I fully support installing in a separate place as a best practice - it just seems weird that poetry will manage everyone else's dependencies through additions/removals, but not its own.

[cauebs]

I don't think it's reasonable to expect that installing Poetry in the same virtual environment as the project it's going to manage won't result in problems like this. I also don't see how Poetry could deal with this. Also, the installation instructions already warn about this, so I don't see how it could be improved.

@toejough Do you have any further suggestions? If not, can you close this?

[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.

[sdispater]

This is not something I plan on adding since the documentation makes it clear that's one of the possible side-effect of this type of installation.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.