Poetry is mainly used for managing an _application_ and its dependencies whereas Hatch is more agnostic to the project type and offers plugin-based functionality for the entire workflow (versioning, tox-like environments, publishing) so you can easily build things other than wheel/sdist, test in a Docker container, etc.
Hatch also strictly adheres to standards and eagerly adopts whatever behavior new PEPs dictate while Poetry has a persistent unwillingness to adopt new standards if they are deemed suboptimal (see comments on PEP 621 [1] and PEP 665 [2])
As such, locking support is temporarily blocked https://ofek.dev/hatch/latest/meta/faq/#libraries-vs-applica...
You can continue using other tools like Poetry at the same time https://ofek.dev/hatch/latest/meta/faq/#interoperability
By the way I very much appreciate the eye for design/UX of Poetry's creator, we also share strong opinions on pipenv :)
[1]: https://discuss.python.org/t/5243/12
[2]: https://github.com/python-poetry/poetry/issues/4710#issuecom...
I'm surprised to hear that view, since when I looked into poetry it seemed more designed for libraries than for (web) applications. I'm thinking specifically about this thread about whether it would be desirable to have a config file option for the --no-root command line flag: https://github.com/python-poetry/poetry/issues/2458
I have to say I do like a lot of the design decisions that have gone into hatch. Regardless, it is great to have more compelling options being worked on, and eventually something will get it "right" enough for the important use cases that it becomes a de facto standard and then hopefully a "blessed" option that everyone can rally around.
Ultimately, I don't really care what I use! But python's woeful package management and distribution is actually a factor in my decision criteria for when and how I use it.
If I control the system end to end? Sure, I don't mind messing with python and building something I deploy. If not, I don't want to deal with it or the headaches that come with the gazillion ways the runtime can be installed/packaged. In this situation I've been defaulting to go even though I'm slightly less productive in it.
I just want a community accepted standard solution that gives me an easy way to offer a pip installable package with its dependencies, or a way to package the runtime easily (cross platform) and move it around with my code so I can forget altogether about what's lurking underneath all that.