publish.yml: the TestPyPI verification step is unreachable (and installs the wrong package name)

[alxmrs]

Found while modelling ddx's PyPI publish workflow on this one — thanks for the reference implementation, it was genuinely useful. Two things in publish.yml that look unintended.

The TestPyPI verification never runs

publish.yml triggers on:

on:
  release:
    types: [published]
  workflow_dispatch:

but both steps in verify-built-dist are gated on a push:

      - name: Publish package to TestPyPI
        if: github.event_name == 'push'          # L186
      - name: Check uploaded package
        if: github.event_name == 'push'          # L190

github.event_name can only ever be release or workflow_dispatch here, so both steps are skipped on every run. The job succeeds without doing anything, which means the whole verify-before-publish safety net is quietly absent — the first real exercise of a wheel is when a user installs it from PyPI.

The install check names the wrong package

Line 193, inside that same (unreachable) step:

uv pip install --extra-index-url https://test.pypi.org/simple --upgrade de

de looks like a truncated xarray-sql. So even once the gate is fixed, the check would install some unrelated package and the import xarray_sql on the next line would pass or fail for reasons unconnected to the build.

Suggestion

Either drop the TestPyPI round trip, or make it reachable — and consider verifying the artifact locally instead, which needs no second index and no token:

      - name: Install the built wheel and exercise it
        run: |
          uv venv --python 3.10
          uv pip install --no-index --find-links dist xarray-sql
          uv run python -c "import xarray_sql; print(xarray_sql.__version__)"

That runs on every trigger, catches a wheel that builds but does not import, and cannot be skipped by a stale event-name condition. A bad PyPI release can only be yanked, never replaced, so this is the last cheap place to catch one.

Happy to send a PR if useful.