Poetry has two flaws imo:

1. It's written in Python, which makes it slower and prone to bootstrapping issues.

2. It doesn't manage your Python installation, which necessitates the use of a tool like pyenv.

Rye sidesteps both of those by (a) being written in Rust and (b) trying to solve all of the problems solved by poetry and pyenv in one go.

I like that it doesn't manage the python/venv installation. E.g. rye creates a .venv for every project and in case of packages that are large, that starts to add up as more projects are added. With poetry, I can separately create a "common" virtualenv which I can use with bunch of throwaway projects; this is of course assuming that the version requirements of these projects do not clash - if they do, I can always create another virtualenv.

With rye, I activated a virtualenv and then created a new project, it proceeded to setup its own .venv within the project instead of just using the one that was already activated.

I would like for more venv sharing, but rye is leaning heavily into correctness, which (in the current Python universe) is much easier to do by recreating the world.

I would consider both of those flaws of Rye, not Poetry. Python package managers not written in Python will by definition have less contributors, and to me, they make Python look like a toy language (you can't write a package manager, a fairly trivial program with the exception of dependency management, in Python - what can you write then?)

As for managing Pythons, I would consider this to be orthogonal to packaging, and the default system Python is often good enough.

The problem with Python for such tools is not so much the speed but that it’s hard to distribute and bootstrap.

I think this is a fine opinion, we like tools that do exactly how much we want them to. But I'd suggest setting up python (and virtual envs) was actually a big headache for a lot of newer users, and some of the old ones (me that is).

I also don't see why leaning into python being a wrapper around rust/cpp/c is a bad thing. Each language has its own niche and packaging/bootstrapping is more of a systems level language problem.

If poetry works for you, it's fine. It works great 90+% of the time for me and I found it before rye or hatch or whatever, so I use it too. Eventually it will either have to adopt to the new standards as they firm up or it will probably get left in the dust, but that's fine. Hopefully if/when that happens something like rye will be mature and boring and well supported everywhere instead.

The latest tools are not always the best tools, old and boring, as long as they work for you are perfectly fine.

Does it automatically install and setup the required Python version for the project?

Yes. You choose a standard version (usually the latest stable 3.12 currently) that it downloads at setup or it downloads and sets up the pinned version from your pyproject.toml.

It doesn’t work consistently across environments

Could you explain futher? By 'environment' do you mean platform?

Like during dev setup, does it work on your friends laptop but not yours, even though you’re both running MacOS latest (this was my experience) Or it works on your laptop but not a CI machine (also my experience).

What we want is for a declarative toml file to reliably reproduce dependencies regardless… sadly even across very similar machines it fails to do so.

isnt this what the lockfile is for? are people installing poetry lock dependencies on macos that turn out different?

I’d recommend reading about Python Wheels - https://realpython.com/python-wheels

Unlike, say NPM, Python doesn’t just download a versioned set of python files depending on your lock file

Probably have different versions of Python installed manually. And/or architecture different.

Poetry struggles with complex packages like PyTorch.