add empty tool.setuptools_scm table to pyproject.toml

[tlambert03]

forgive the somewhat indirect/weird PR.

I ran into an issue trying to install pygfx into a centos docker container. It depends on uharfbuzz and presumably no wheel was available and so it tries to build from source, at which point I got this error:

× Failed to build `uharfbuzz==0.45.0`                                                                                                            
├─▶ The build backend returned an error                                                                                                          
╰─▶ Call to `setuptools.build_meta.build_wheel` failed (exit status: 1)   
...
[stderr]
WARNING setuptools_scm.pyproject_reading toml section missing
'pyproject.toml does not contain a tool.setuptools_scm section'
Traceback (most recent call last):
  File
"/root/.cache/uv/builds-v0/.tmp6PFCYC/lib/python3.12/site-packages/setuptools_scm/_integration/pyproject_reading.py",
line 36, in read_pyproject
    section = defn.get("tool", {})[tool_name]
              ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'setuptools_scm'
error: command 'c++' failed: No such file or dir

... whether the build would have succeeded after that I admit I have no idea... but the error does seem correct according to the setuptools-scm docs, which state that a table should be included (even if empty)

[tool.setuptools_scm]
# can be empty if no extra settings are needed, presence enables setuptools-scm

(edit: i acknowledge that it states a warning, before a KeyError... and it's still not entirely clear that the missing table is what actually bombed the build... but it seems like the correct addition anyway)

[tlambert03]

update, I can confirm that having all the necessary dev tools in the container does build successfully, so you can consider this PR entirely optional (it would simply remove the warning)

[khaledhosny]

Linux CI failed and the failure seems related to this change. I’m going to close this PR, but please re-open if you are interested in fixing the CI failure.

[tlambert03]

sounds good. if I have time to figure out what's going on with the linux wheel building i'll reopen 👍

[HinTak]

That shouldn't be arbitrary? The CI log is under the action tab, and I am a little surprised I (somebody with no formal association with the project; some project restricts it to either the originator or the project owner / collaborator) can read it, but here you go:

=================================== FAILURES ===================================
  ____________________________ test_uharfbuzz_version ____________________________
  
      def test_uharfbuzz_version():
          v = hb.__version__
          assert isinstance(v, str)
  >       assert "unknown" not in v
  E       AssertionError: assert 'unknown' not in '0.0.0+unknown'
  E         
  E         'unknown' is contained here:
  E           0.0.0+unknown
  
  /project/tests/test_uharfbuzz.py:1607: AssertionError

[tlambert03]

sorry if my statement was confusing. I know how to see the logs :) ... i just don't know exactly why linux is failing to extract the version from the git tags, while windows and macos are not. and don't currently have time to look into it

[HinTak]

I think I have a guess of the answer - CI on github (particularly when it involves docker containers etc) does not nessarily do a git clone -depth 1 ... ; git checkout <target_hash> thing, since github has direct access to the object store behind the repository. In a container, it would do the clone + checkout .. step if git itself is installed in the container, but would read directly from git's object store if not, and hence does not have the git tags etc in that situation. Mac and Windows CI does the traditional clone -depth 1 thing, but not necessarily on Linux. I know that's the situation if you say, run a ubuntu-not-default container inside the usual ubuntu ci host.

[tlambert03]

that's true... but they explicitly fetch tags here:

uharfbuzz/.github/workflows/ci.yml

Lines 72 to 84 in 31cfa76

	git fetch --tags --force
	# Dump tag message body to temporary .md file
	echo "$(git tag -l --format='%(contents:body)' ${{ github.ref_name }})" > "${{ runner.temp }}/release_body.md"
	# Set RELEASE_NAME env var to tag message subject
	echo "RELEASE_NAME=$(git tag -l --format='%(contents:subject)' ${{ github.ref_name }})" >> $GITHUB_ENV
	# if the tag has a pre-release suffix mark the Github Release accordingly
	if egrep -q "$PRERELEASE_TAG_PATTERN" <<< "${{ github.ref_name }}"; then
	echo "Tag contains a pre-release suffix"
	echo "IS_PRERELEASE=true" >> "$GITHUB_ENV"
	else
	echo "Tag does not contain pre-release suffix"
	echo "IS_PRERELEASE=false" >> "$GITHUB_ENV"
	fi

[HinTak]

That's an entirely different (and much later) section of CI than build and test. You are failing much earlier / unrelated to the section of CI you quoted.

[tlambert03]

great, then perhaps checkout with fetch_depth of 0 will fix it. point was i didn't have time to look into it :) if you have a theory, give it a shot! 👍