New release: 0.22.0

@Siyet

Hi 👋

@Siyet @provinzkraut @ofek Can we please make a new release? I need some of the changes in django-modern-rest, which depends on msgspec :)

I've never released a new version of msgspec yet, but I can see that trusted publishing is setup here:

msgspec/.github/workflows/ci.yml

Lines 192 to 224 in 593ec54

    
           build-wheels: 
        
             name: Build wheels ${{ github.event_name == 'release' && 'for release' || '' }} 
        
             needs: 
        
             - test 
        
             - prepare 
        
             uses: ./.github/workflows/build-wheels.yml 
        
             permissions: 
        
               actions: read 
        
               contents: read 
        
             with: 
        
               sdist-name: "${{ needs.prepare.outputs.sdist-name }}" 
        
               build-all: ${{ github.event_name == 'release' }} 
        
           upload-pypi: 
        
             name: Upload artifacts to PyPI 
        
             if: github.event_name == 'release' && github.event.action == 'published' 
        
             needs: 
        
             - prepare 
        
             - build-wheels 
        
             runs-on: ubuntu-latest 
        
             permissions: 
        
               actions: read 
        
               id-token: write 
        
             steps: 
        
             - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c  # v8.0.1 
        
               with: 
        
                 pattern: artifact-* 
        
                 merge-multiple: true 
        
                 path: dist 
        
             - name: Publish package distributions to PyPI 
        
               uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b  # v1.14.0

So, if this is fine, I can make one myself :)

Ok, since I did not recieve any "no", I will take an action and release a new version. I really need some of the bugfixes in my project :)

Wish me luck!

Ok, it did not work :(

Building cp310-musllinux_riscv64 wheel
CPython 3.10 musllinux riscv64
Setting up build environment...
      + mkdir -p /
      + /opt/python/cp39-cp39/bin/python -c 'import sys, json, os; json.dump(os.environ.copy(), sys.stdout)'
      + which python
      + python -V -V
  Python 3.10.20 (main, Jun  4 2026, 13:38:41) [Clang 22.1.6 ]
      + which uv
Error: cibuildwheel: Command ['which', 'uv'] failed with code 1. 
                                                              ✕ 1.59s

Fails consitently: https://github.com/msgspec/msgspec/actions/runs/31476259980/job/93742042390

I propose skipping riscv on musllinux for now. The use-case seems VERY rare.

Sorry, my matrix entry is what broke your release.

The manylinux riscv64 wheels all built and tested fine in that run. Only musllinux fails, and I think it's a stale image pin rather than anything riscv-specific.

pypa/manylinux used to skip installing uv in the musllinux riscv64 image, with the comment "uv doesn't provide musl riscv64 wheels due to Rust issues" in finalize.sh. That was removed in pypa/manylinux#1969 on 11 July, and their image tests exercise uv there now. cibuildwheel 4.1.0 pins the 2026.06.04-1 image, which predates the fix, so build[uv] has no uv to find. 4.2.0 pins 2026.08.04-1, which does.

So bumping the two cibuildwheel==4.1.0 pins in build-wheels.yml to 4.2.0 might be all that's needed, without dropping the wheels. If you'd rather not move cibuildwheel right before a release, musllinux-riscv64-image in .cibuildwheel.toml pins just that one image instead.

I haven't run either yet. Happy to open a PR and let CI confirm. And no objection to skipping musllinux riscv64 in the meantime if you want 0.22.0 out today.

Opened #1146 with the cibuildwheel bump. Still untested, as I noted there, so skipping musllinux riscv64 remains the safer path if you want 0.22.0 out today.

Bump cibuildwheel to 4.2.0 to fix musllinux riscv64 wheels (msgspec#1146

Version 0.22.0 release, attempt 2 (msgspec#1147)

riscv64 came back green on the release run: all twelve wheels built and tested, including the six musllinux ones that failed before.

The run is still red, but it stopped further along, at Upload artifacts to PyPI:

Trusted publishing exchange failure:
* `invalid-publisher`: valid token, but no corresponding publisher (Publisher with matching claims was not found)

The wheels are all attached to that run, so nothing needs rebuilding once the publisher config lines up.

This still fails: https://github.com/msgspec/msgspec/actions/runs/31489076277/job/93783511854


  Error: Trusted publishing exchange failure: 
  Token request failed: the server refused the request for the following reasons:
  
  * `invalid-publisher`: valid token, but no corresponding publisher (Publisher with matching claims was not found)
  
  This generally indicates a trusted publisher configuration error, but could
  also indicate an internal error on GitHub or PyPI's part.
  
  
  The claims rendered below are **for debugging purposes only**. You should **not**
  use them to configure a trusted publisher unless they already match your expectations.
  
  If a claim is not present in the claim set, then it is rendered as `MISSING`.
  
  * `sub`: `repo:msgspec@287455683/msgspec@332952543:ref:refs/tags/0.22.0`
  * `repository`: `msgspec/msgspec`
  * `repository_owner`: `msgspec`
  * `repository_owner_id`: `287455683`
  * `workflow_ref`: `msgspec/msgspec/.github/workflows/ci.yml@refs/tags/0.22.0`
  * `job_workflow_ref`: `msgspec/msgspec/.github/workflows/ci.yml@refs/tags/0.22.0`
  * `ref`: `refs/tags/0.22.0`
  * `environment`: `MISSING`
  
  See https://docs.pypi.org/trusted-publishers/troubleshooting/ for more help.

@ofek

@ofek @jcrist can you please help me with this? I think that the publisher configuration is outdated or something? The release was not successful. I will delete the release / tag, so we can recreate it again.

The issue is that the repository claim is no longer correct after the repo transfer. I just put in a request on PyPI for a dedicated msgspec organization and bumped it in Discord. Whenever Jim sees this, he can either create a new trusted publisher or if I reply before then he can transfer the project to the org and I can do that myself.

Possibly relevant, though this is inference from dates rather than anything I can actually see on PyPI.

The last successful upload was 0.21.1 on 12 April, and the msgspec org was created on 24 May. So every release that has published through trusted publishing did so while the repo was still jcrist/msgspec, and the claims now say repository_owner: msgspec. If the publisher registered on PyPI still lists jcrist as the owner, that would give exactly this error.

Worth a glance at environment too while you are in there, since the claim set shows it as MISSING and upload-pypi has no environment: key. That only bites if the publisher was configured with an environment name.

If the publisher does predate the transfer, updating it may need whoever owns the project on PyPI rather than the GitHub side.

friendly ping :)

@jcrist

@jcrist gentle ping on this one, since it has been sitting for a few weeks.

0.22.0 is ready apart from the upload. After #1146 the full wheel matrix builds and tests green, and the release run got all the way to Upload artifacts to PyPI before failing on trusted publishing. The only thing nobody here can look at is the publisher configuration on the PyPI side.

The claims from the failing run were:

repository: msgspec/msgspec
repository_owner: msgspec
workflow_ref: msgspec/msgspec/.github/workflows/ci.yml@refs/tags/0.22.0
environment: MISSING

Either of these unblocks it, whichever suits you:

add a trusted publisher on the PyPI project with owner msgspec, repository msgspec, workflow ci.yml, and no environment (our upload-pypi job does not set one, so the environment field has to stay empty to match);
or transfer the project to the msgspec PyPI organization @ofek requested, and he can configure it himself.

No rush if you are busy, but a one-line answer on which way you would prefer would let us stop waiting or take it off your hands. Happy to redo the tag and the release run once the publisher is in place.

Add missing 0.22.0 changelog entries (msgspec#1171)

Build the full wheel matrix weekly, not only at release (msgspec#1174)

The new trusted publisher is configured, feel free to create the release!

Awesome, I will do this today! 🎉

Move the unreleased changes into the 0.22.0 changelog (msgspec#1211)

@sobolevn

Thx @sobolevn for the quick reveiws and merges, and for taking care of the release!

Having several more PRs in the release would be awesome:

Rolling the release! Wish me luck 🙏

Release 0.22.0 is now live!

PyPI: https://pypi.org/project/msgspec/0.22.0/
GitHub: https://github.com/msgspec/msgspec/releases/tag/0.22.0
Job: https://github.com/msgspec/msgspec/actions/runs/36571319643

Thanks everyone for their help!

Navigation Menu

Repository navigation

New release: 0.22.0 #1134

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	build-wheels:
	name: Build wheels ${{ github.event_name == 'release' && 'for release' \|\| '' }}
	needs:
	- test
	- prepare
	uses: ./.github/workflows/build-wheels.yml
	permissions:
	actions: read
	contents: read
	with:
	sdist-name: "${{ needs.prepare.outputs.sdist-name }}"
	build-all: ${{ github.event_name == 'release' }}

	upload-pypi:
	name: Upload artifacts to PyPI
	if: github.event_name == 'release' && github.event.action == 'published'
	needs:
	- prepare
	- build-wheels
	runs-on: ubuntu-latest
	permissions:
	actions: read
	id-token: write

	steps:
	- uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
	with:
	pattern: artifact-*
	merge-multiple: true
	path: dist

	- name: Publish package distributions to PyPI
	uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0

New release: 0.22.0 #1134

Description

Activity

sobolevn commented on Aug 11, 2026

sobolevn commented on Aug 11, 2026

sobolevn commented on Aug 11, 2026

gounthar commented on Aug 11, 2026

gounthar commented on Aug 11, 2026

gounthar commented on Aug 11, 2026

sobolevn commented on Aug 11, 2026

sobolevn commented on Aug 11, 2026

ofek commented on Aug 11, 2026

gounthar commented on Aug 11, 2026

sobolevn commented on Aug 29, 2026

Siyet commented on Sep 4, 2026

ofek commented on Sep 28, 2026

sobolevn commented on Sep 29, 2026

Siyet commented on Sep 29, 2026

sobolevn commented on Sep 29, 2026

sobolevn commented on Sep 29, 2026

sobolevn commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions