brentyi / tyro

CLI interfaces & config objects, from types
https://brentyi.github.io/tyro
MIT License
514 stars 27 forks source link

Why move away from poetry? #58

Closed kevinddchen closed 1 year ago

kevinddchen commented 1 year ago

Just genuinely curious. I've never used poetry before, but I've been curious and always wanted to try out.

Were there any pain points in particular?

brentyi commented 1 year ago

It was a combination of not benefitting from the primary benefits of poetry + pain points with usage in practice.

My impression of poetry is still generally positive, but I had some (mostly) tyro-specific issues with it:

  1. Repeatability from the dependency lock file is a main draw of poetry, but since tyro is so low-level I found myself actually wishing for more chaos in dependencies. If a new version of a dependency's released, tests wouldn't be run using it unless I updated the lock file.

  2. I preferred using conda over Poetry's built-in environment manager. Poetry plays nice with conda, with the nuance that it includes the very-reasonable-but-nonetheless-friction-inducing behavior of uninstalling packages that aren't in your dependencies.

  3. Both myself and @tancik (for a different project) found ourselves spending mornings struggling with keyring errors (https://github.com/python-poetry/poetry/issues/1917).

  4. The lock file + dependency resolver was slow and would often fail. The breadth of permutations of Python versions (3.7 ~ 3.11) as well as systems (M1 Mac, Ubuntu CPU, Ubuntu w/ GPU, ...) we're supporting introduces a lot of challenges. As an example, the latest version of scipy that the lock file will accept with that range of Python versions is 1.6.1 from early 2021, but 1.6.1 doesn't have wheels or seem to build for M1 Macs. scipy==1.6.2 fails because it requires Python <3.10, and of course newer versions drop support for 3.7 and 3.8.

kevinddchen commented 1 year ago

I see, thank you for your thorough response.

Your first point makes a lot of sense: (to me at least) tyro feels like a library since it's meant to be incorporated into any project, thus pinned dependencies doesn't make too much sense, aside from providing a stable environment for testing. Allowing "chaos" in dependencies can test for possible points of failure within the library itself.

Second point definitely sounds annoying too.

I think this actually wants me to try poetry even more, and experience the pain firsthand haha.