[k1rcher]

I’ve noticed Poetry being used more and more for projects I setup locally, and I must say, it does seem to be very, very good. Minimal overhead, easy to adopt, etc. I’ll need to setup a proper workflow with it for my current projects. Being able to abstract dev/prod environments in particular are really handy.

[mumblemumble]

I'm sort of the Python hero at work, and, for me, the one supremely magical thing that Poetry brings to the table is that I am finally able to spec out a Python development workflow that I can easily document and explain to team members who don't already have a lot of detailed Python expertise.

Maybe the single most underappreciated thing about Poetry compared to other options is its tendency to fail safe.

[stavros]

Agreed, I really like it. It does everything and does it well, zero complaints so far.

[bigbillheck]

I managed to find an annoying situation with poetry in which if you specify a range of versions for a dependency, and one of your other dependencies specifies a slightly different range of versions for that dependency, it will refuse to proceed. (I was expecting it to have chosen something in the intersection of the ranges, but it did not)

[stavros]

Hm, yeah, that definitely sounds like a resolver bug. Did you report it? I'm curious to see if it was fixed.

[code_biologist]

I suspect in GP's case there was something blocking the intersected range. That should work perfectly.

The poetry author doesn't want to support package version range overrides like yarn does [1]. His call I suppose, but I think it's the one major flaw in the otherwise giant step that poetry takes forward.

[1] https://github.com/python-poetry/poetry/issues/697

[bigbillheck]

I did not report it because I found somebody else had already reported it and it was a WONTFIX (for reasons I don't immediately recall).