Actually working out the right configuration for your project is likely going to take you more than 30 seconds. And finding the documentation for how to do this is only quick if you know exactly where to look and what to look for. When you invoke pyproject-build it’s not clear that hatch is the piece of the puzzle that’s causing unexpected files to wind up in your sdist.

And this is still more config and overhead than simply choosing a build backend with more sensible default behavior like uv_build.

Interesting discussion, thanks for the link! I side with pf_moore there; when I think of distributing a library I think of shipping only the library code itself and none of the supporting files, although I can understand the argument to include things like tests/ and docs/.

That said, if you haven’t already tailored your project for hatch, configuring only-include is more work than switching to a build backend that just bundles source modules by default. With the right config hatch can do what you like, and I can understand existing users sticking with it, but for newbies I think it’s really risky to suggest a build backend that grabs everything it finds in the working directory and packages it up for PyPI. It’s just surprising and dangerous default behavior imo.

Even if you’re using git or hg for version control you’ll probably wind up with more in your sdist than you need: things like uv.lock, Justfile, or the contents of your tests/ dir might not be harmful, but they bloat your sdist and don’t really belong there, and hatch will package them up with your source code unless you explicitly configure it not to.