Removing all custom complexity (leveraging base requirements format for .lock files)
Since rye manages both python installations AND project management, it can ensure a correct python is being used for maintainers and contributors, a really key fact that trumps the current poetry setup. It also leverages a much simpler setup for dependency locking (using the same resolver as pip) and avoids bootstrapping issues (and gains speed) from being a rust project (instead of a python/shell tool).
Considerations
I'm a bit hesitant to migrate this repo again from one project management tool to another, as a symptom of "shiny object syndrome". rye is also a newer tool, unlike poetry, and lacks a bit of the foundation (esp. from industry) that poetry has gained w/ experience overtime. The community resources is necessarily weaker (growing) and there will be growing pains if we did make this move. I've already ran into some small barriers of missing features from poetry in rye.
The main reason why I think it's a good idea is to really simplify the tooling we both use and recommend, especially from the point of view of simplistic python installations that match for project development (won't harm whatever python situation you have going on). It specifically aims to never compile python to your system (unless you chose to) which fixes a whole load of issues with pyenv. Python installations vary so widely among systems that it can get a bit awkward to manage (w/ shell shims and global environments galore). I've seen this first hand with the struggle of getting a working poetry setup.
I've started using it for some personal projects and I've greatly enjoyed the simplicity in the design (for example, it outputs requirements.lock that can be pip installed naturally, making Dockerfiles and Github Action workflows simpler).
ryeis a newer, rust based tool for python management, inspired bycargo's utility in the rust ecosystem.It has tooling for
pyenv)pyproject.toml(likepoetry)pipx)It's designed to be:
cargois to rust.requirementsformat for.lockfiles)Since
ryemanages both python installations AND project management, it can ensure a correct python is being used for maintainers and contributors, a really key fact that trumps the currentpoetrysetup. It also leverages a much simpler setup for dependency locking (using the same resolver aspip) and avoids bootstrapping issues (and gains speed) from being a rust project (instead of a python/shell tool).Considerations
I'm a bit hesitant to migrate this repo again from one project management tool to another, as a symptom of "shiny object syndrome".
ryeis also a newer tool, unlikepoetry, and lacks a bit of the foundation (esp. from industry) thatpoetryhas gained w/ experience overtime. The community resources is necessarily weaker (growing) and there will be growing pains if we did make this move. I've already ran into some small barriers of missing features frompoetryinrye.The main reason why I think it's a good idea is to really simplify the tooling we both use and recommend, especially from the point of view of simplistic python installations that match for project development (won't harm whatever python situation you have going on). It specifically aims to never compile python to your system (unless you chose to) which fixes a whole load of issues with
pyenv. Python installations vary so widely among systems that it can get a bit awkward to manage (w/ shell shims and global environments galore). I've seen this first hand with the struggle of getting a workingpoetrysetup.I've started using it for some personal projects and I've greatly enjoyed the simplicity in the design (for example, it outputs
requirements.lockthat can bepipinstalled naturally, makingDockerfiles and Github Action workflows simpler).