If it is a string then it is a path relative to pyproject.toml to a text file containing the full description.
It says nothing about whether the paths must be inside the project directory or not. So the following value is allowed:
readme = "../../README.md"
When encountering such a path, build backends either reject it with an error(setuptools), or preserve the relative paths in the sdist(hatchling, pdm-backend), which lead to an error when trying to extract it via tarfile module.
I believe the spec needs to clarify how the build backend should handle these relative paths: either disallow them, or specify that the built sdist must remain valid. I personally lean towards the latter, as this would be very useful in a monorepo.
Or people just need to be made aware that it’s probably not going to work, and we can leave the spec as it is.
Build backends can already choose how to handle this. If there’s a problem with how some handle it, report a bug to them. No need to impose a design via spec here.
Agreed. There’s nothing wrong with such filenames - technically, a build backend could read the referenced file and store the data in the Description field in the sdist metadata with the value marked as not being dynamic, which would allow builds from the sdist to work even if the referenced file is not present. But I don’t think there’s a reason to mandate that behaviour.
Probably the worst behaviour is what you describe hatchling and pdm-backend doing, which is to build a sdist which won’t actually work. But that’s still just user-unfriendly, and can be fixed via a bug report to the relevant backends. The backends can then choose how to fix the issue (give an error or produce a valid sdist).
We could potentially add a non-normative editorial note somewhere on packaging.python.org about the problem. No obvious location for it comes to mind, though.