Hacker News Reader

Comment by 1propionyl | Hacker News Reader

Rough edges as they may be, I'm just going to put my chips on Hatch because it works well, the defaults for build/formatting/testing/publication are sane and built on other tools, I can actually read the source code easily enough to PR it (which I have done), and it's under the auspices of the PyPA. In short, it's a good facade.

Also, the CLI tooling doesn't even depend on using Hatchling as a build system, which is an understated benefit.

Unless one's got a particularly weird use case where they actually need to know the ins and outs of PEP 517 (Maturin/PyO3 with system specific dependencies, for example) it is going to be completely fine for the vast majority of packages with minimal additional configuration.

View on HN

Hatch is very featureful and achieves a lot, but for me, a lot of the defaults and how it's configured is entirely backwards from what I expect. I've concluded it is not for me.

My concrete suggestion is that Hatch would be better for me if it was developed by a team and not a single person. Then its core ideas would be judged by multiple people from different angles. As it is now, it's written to the taste and philosophy of a single author.

That may be the case, but my experience from submitting issues is that ofek is very receptive to other's perspectives and spends a lot of time engaging with other takes in issues on the Hatch repo and elsewhere.

As an example I see he's in this thread replying to a cousin comment :).

Sidebar: the benefit of one person early on in a project's development is that it's much easier to establish conceptual integrity in the Fred Brooks sense: "Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds".

One person's coherent vision can be very good for a project, I think so too!

I’ve used both Hatch and Rye extensively. Hatch is great, but currently lacks monorepo support (it is expected to be added by the Autumn). I do like the way that Rye bootstraps itself, the dependency resolver does seem to be much faster, I like that you get updated pip lockfiles on every sync, and it already has opinionated monorepo support. Getting a new developer spun up is as easy as “rye sync”. But I agree that the fact that Hatch is under the auspices of the PyPA is persuasive indeed.

Rye for some reason requires that you put dev dependencies under a non-standard key in pyproject.toml, but other than that, it’s pretty trivial to swap between Hatch and Rye as you like (which was indeed one of the primary goals of PEP621 afaiu). I for one will certainly be checking in on Hatch again when monorepo support is added.

Workspaces is unblocked now, it depended on a large refactor which has now been merged: https://github.com/pypa/hatch/pull/1602

In my free time, it's the only thing I'm working on!

Awesome, thank you. Happy Hatch user.

Excellent news - thank you for all of your excellent work on Hatch!

Reply on news.ycombinator.com