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
      61·
      1 month ago

      It’s the conservative choice, which is maybe not ideal for new projects as it predates many PEPs. Hatch, uv, poetry, pdm, are probably all better modern choices.

        • Eager Eagle@lemmy.worldEnglish
          3·
          1 month ago

          Caution

          If you use setuptools, please be aware that some features that predate standardisation efforts are now deprecated and only temporarily kept for compatibility.

          In particular, do not use direct python setup.py invocations. On the other hand, configuring setuptools with a setup.py file is still fully supported, although it is recommended to use the modern [project] table in pyproject.toml (or setup.cfg) whenever possible and keep setup.py only if programmatic configuration is needed. See Is setup.py deprecated?.

          Other examples of deprecated features you should not use include the setup_requires argument to setup() (use the [build-system] table in pyproject.toml instead), and the easy_install command (cf. pip vs easy_install).

          https://packaging.python.org/en/latest/guides/tool-recommendations/

          it’s just easier to have a modern hassle-free setup with the other tools