Inspired by @fcodvpt post about current popularity of build backends, I investigated how the popularity of build backends used in pyproject.toml evolved over time since PEP-0517 introduced them in 2015:
@venthur@fcodvpt nice stats! I would have expected flit to have higher percentage. The python packaging is still in the middle of changes and it's interesting to see where this is going and what kind of tools we will be using in five years from now.
@fohrloop@venthur@fcodvpt Flit is a bit of a special build back-end as it has no dependencies and very simple, so it's typically used to help bootstrap packaging projects themselves. Compare that to Hatchling and pdm-backend which has some nice-to-haves.
@fohrloop@venthur@fcodvpt How do you generate your sdists? And then after that is when folks want something slightly fancier like dynamic version numbers that require a plug-in.
@fohrloop@brettcannon@venthur@fcodvpt One thing I've heard is that packagers for downstream repositories (e.g. Linux distribution package managers) prefer or even insist on sdists because they need the test code and/or documentation. There can be other tools that are trying to do things other than installing your package that can't work with a wheel, they need an sdist.
BTW you can use python -m build to build a project and get both the sdist and wheel "for free".
And yeah, dynamic versioning is great. I've had so many problems with hard-coding the version number in a file; IMO it's so much easier to just determine it from the tag. So this is the "killer feature" that makes me choose hatch (or setuptools back in the day before hatch supported it) over other backends.
@fohrloop@brettcannon@venthur@fcodvpt FWIW it's not actually guaranteed that sdists have tests and docs included. I mean, ultimately an sdist is just a .tar.gz archive that follows a few standards, but I don't think those standards govern what goes in the repo, except for the PKG-INFO file which needs to contain some metadata. (Technically I don't think an sdist even needs to contain the package's own source code! You could make a valid sdist with almost nothing in it - useless, but valid.)
However, the way most build tools are configured, they'll put everything in the sdist by default, so it's common to have tests+docs in there, and a certain subset of consumers have come to rely on that.
@fohrloop@brettcannon@venthur@fcodvpt Oh interesting. That could be, but I do seem to remember that flit will omit any Python files other than a single top-level directory or Python file whose name matches the package name. Or something like that. Maybe that causes it to exclude tests and docs.
Every build backend has its own rules about what files it includes in an sdist, and it wouldn't surprise me if flit is one of the most conservative in that sense. Of course, that probably does mean that if you ever want to get your package included in a Linux distro or some other context where tests and/or documentation are important, you need to use something other than flit.
@diazona@fohrloop@venthur@fcodvpt It's flit and why I said sdist support is a differentiation between the tools. Flit doesn't include much, Hatch is everything included by your git repo, and PDM tried to be smart about it
Add comment