3
New to Python packaging? Avoid hatch (danpassaro.dev)
submitted 6 days ago by to c/python@programming.dev
26 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [S] 3 points 6 days ago (2 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [โ€“] 7 points 6 days ago* (1 child)

    you just need only-include

    https://hatch.pypa.io/1.13/config/build/#explicit-selection

    it's easier than changing build backends

    and a lot of times tests/ (and docs/) are included with source code in an sdist format - https://discuss.python.org/t/should-sdists-include-docs-and-tests/14578

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [โ€“] [S] 2 points 6 days ago*

    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.

  • permalink
  • fedilink
  • source
  • parent