removing bpython removed requests, which poetry needs about poetry HOT 11 CLOSED

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.

from poetry.

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.

from poetry.

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.

from poetry.

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?

from poetry.

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.

from poetry.

also, installing with pipsi worked great.

from poetry.

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.

from poetry.

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.

from poetry.

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?

from poetry.

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.

from poetry.

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.

from poetry.