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.
  • Eager Eagle@lemmy.worldEnglish
    0·
    2 months ago

    hatch has hardcoded awareness of Git and Mercurial and specifically searches for project-level .gitignore and .hgignore to read those files directly. But it doesn’t handle user-level or system-level config, so anything you have ignored from config outside of your project, like .env in my example, will not be ignored by hatch, and will wind up in your sdist.

    ah that probably explains why I didn’t have this problem, same reason why I don’t like global gitignores

    • esc@piefed.socialEnglish
      0·
      2 months ago
      [tool.hatch.build.targets.sdist]
include = [
  "pkg/*.py",
  "/tests",
]
exclude = [
  "*.json",
  "pkg/_compat.py",
]

      It takes about 30 seconds of reading the documentation to find this.

      • dan_p_the_dev@lemmy.worldOP
        1·
        2 months ago

        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.

        • esc@piefed.socialEnglish
          01·
          2 months ago

          Please, you’ve wasted a lot of time writing the article without bothering to read documentation (it’s mentioned in both python guide and on the hatchling page), which takes one click and like three paragraphs down, and uv_build requires to use uv and not everyone likes it or wants to use it. Anyway reading documentation is far more important for beginners than automagical tools that supposedly solve all the problems in the world.

          • dan_p_the_dev@lemmy.worldOP
            1·
            2 months ago

            Please, you’ve wasted a lot of time writing the article without bothering to read documentation

            ? I linked directly to the documentation I read, and that’s how I wound up using hatch in the first place. Did you read my article…? Reading the official Python documentation is what led to me uploading my .jj folder and a gitignored .env file to PyPI and writing this post. And writing the post was not a waste of time.

            uv_build requires to use uv and not everyone likes it or wants to use it

            That’s fine. I’m sure there are other build backends that work similarly to uv_build and only grab what’s needed to distribute your library. The point isn’t that everyone needs to use uv_build, the point is that hatch has surprising and imo dangerous default behavior.

            • esc@piefed.socialEnglish
              01·
              2 months ago

              You see, I’ve actually read your article, you even linked to the hatchling site yourself. It takes little effort. Demonstration

  • logging_strict@programming.dev
    01·
    2 months ago

    There is no way for xyz to be either included or excluded from a package cuz everyone should be running python -m build and checking the tarball and .whl before 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.