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.
There is no way for xyz to be either included or excluded from a package cuz everyone should be running
python -m buildand checking the tarball and.whlbefore even considering a commit or a release.So although the OP chose hitch that doesn’t change the workflow of manually checking the tarball.
I use setuptools, wreck (requirements management), and drain-swamp (choose versioning by either “tag” or “current” rather than specifying exact semantic version). What i use has no bearing on the opinion above.
“modern” means you are a little bitch. I’m very tired of that term. A function with multiple return statements is considered “modern”. Whereas i see that as wrong. So now that “modern” word is being thrown around for packaging?! Please stop using that term. It’s a cope for not being able to code your own build backend (drain-swamp), frame stack free locals inspection (logging-strict), and requirements management (wreck)!
Use whatever you are familiar with without peer pressuring others.