I recently built a Python library for the first time in a while, and to make it available in PyPI I followed the official Python packaging guide. But it turns out there’s some rough edges in the suggested tools.
Namely, the build backend hatch puts all the files in the project directory into the built sdist, except from some files it chooses to exclude, which led to a gitignored file as well as VCS metadata getting packaged and uploaded to PyPI. This really surprised me, and I think most Python users new to packaging would be better served by choosing a conservative build backend like uv_build, which puts only the Python source modules and some specific project-level files into the sdist.
you just need
only-includehttps://hatch.pypa.io/1.13/config/build/#explicit-selection
it’s easier than changing build backends
and a lot of times
tests/(anddocs/) are included with source code in an sdist format - https://discuss.python.org/t/should-sdists-include-docs-and-tests/14578Interesting 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/anddocs/.That said, if you haven’t already tailored your project for hatch, configuring
only-includeis 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.