Subtle backward incompatibility in PEP 725?

[kknechtel (Karl Knechtel)]

@pf_moore

Not if building from a sdist (which is by definition not a git checkout).

Just the other day I saw a case of an sdist that seemed to be broken along those lines. As I understood it, the build backend was expecting to use a version from a file that cached a setuptools-scm result, but the sdist tarball didn’t actually appear to contain the file.

@pf_moore

Is it the build backend’s responsibility to determine, for example, that when pyproject.toml in a source tree says “depends on git”, the sdist built from that source tree no longer depends on git and so that dependency should not be present in the sdist metadata? If not, isn’t the sdist metadata wrong?

I would say the metadata is wrong, and further that the tooling is working wrongly. In my view, because pyproject.toml is included in an sdist, it’s about explaining how a wheel is produced from an sdist. If there’s something interesting about producing an sdist from the repo, then that should be handled separately - and it’s fine if that produces an sdist containing a pyproject.toml that differs from the repo’s pyproject.toml, as long as the packaged version correctly describes the sdist and allows for building a correct wheel.