Add Windows x86_64 Wheels to Release Workflow by posborne · Pull Request #109 · fastly/compute-sdk-python

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne · 2026-06-02T18:59:59Z

Building CPython for WASI presents a bunch of issues; I ended up following what is done by componentize-py by building CPython target WASI once on Linux and doing the delicate dance to reuse that artifact when rounding out the platform-specific wheel.

I was hoping this might reduce CI times as we avoid having to build CPython more than once; while that is the case, we end up having to rebuild chunks of the dependency graph in both stages, so CI time is increased. Eventually, I think upstream componentize-py might look to reuse prebuilt CPython releases for WASI, but that will require some more work and belongs in upstream.

https://github.com/fastly/compute-sdk-python/actions/runs/26839132628 shows the successful run. I tweaked the triggers on the workflow a bit to make it easier to do manual dispatches. CI will also run the release workflow on PRs that modify the release.yml file as well (but only on tag will we create a pre-release).

…check constraints

Following what is done by componentize-py more closely, build and store the artifact for our source-built CPython targeting WASI once on linux. Then place this CPython in a place it will be picked up for platform-specific wheel builds. This should reduce the total overall CI work, reduce complexity, and enable us to support Windows where there are issues with tooling to build CPythong from source for WASI (that we would rather not have to try to solve). It _might_ be possible to reduce CI times further in the future by caching this CPython build, but for now keeping it simple.

`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

We don't need these and they cause problems on Windows; just exclude them when creating the archive.

We had diverging ways of doing this path lookup, converting the path to posix form, etc. There was also a bug with the path lookup in the manylinux container. Make this consistent by having extracting the functionality to a small helper script based around cargo metadata's json output.

erikrose

Hooray! Want to push a 0.1.2 pretty soon? I hear some people use Windows.

erikrose · 2026-06-02T20:38:02Z

 .github/scripts/setup-nightly.sh ${{ env.RUST_NIGHTLY }}
 rustup target add wasm32-unknown-unknown
+ cargo fetch
+ MANIFEST_DIR=$(cargo metadata --format-version=1 | jq -r '.packages[] | select(.name == "componentize-py") | .manifest_path' | xargs dirname)


Took me a minute to guess what's going on here. Are you sticking the previously built CPython-for-wasi into the build dir so the Linux build doesn't rebuild it? (Is it smart/dumb enough not to rebuild it?)

Yep, that's what's going on. Primarily motivated by Windows not being able to build CPython at all presently (but should be reused for all of the second-pass builds). This is the model used by componentize-py to get windows working and what I ended up adopting here.

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

posborne added 8 commits June 2, 2026 11:27

release: run workflow on branch push touching release.yml, relax tag …
9e8f5b5
…check constraints

release: Add Windows x86_64 wheel support
92b7603

release: fix pathing issues on Windows
f3d170a

release: jq not available in manylinux containers, use find
8bf524e

release: hack to reduce work done in cpython build stage
9eb8a68
`cargo check` will run build.rs (which builds CPython) but hopefully will reduce other compilation work that we subsequently discard.

release: don't include directories/files with symlinks
3bc9d1a
We don't need these and they cause problems on Windows; just exclude them when creating the archive.

posborne requested a review from erikrose June 2, 2026 18:59

release: script format and lint ignore
1025d0e

erikrose changed the title ~~Add Windows x86_64 Wheels to Relase Workflow~~Add Windows x86_64 Wheels to Release WorkflowJun 2, 2026

erikrose approved these changes Jun 2, 2026
View reviewed changes

posborne merged commit dfa0d56 into mainJun 2, 2026
11 checks passed

Uh oh!

Conversation

posborne commented Jun 2, 2026

Uh oh!

erikrose left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

posborne commented Jun 2, 2026

Uh oh!

erikrose left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

posborne commented Jun 2, 2026

Uh oh!

erikrose left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

posborne commented Jun 2, 2026

Uh oh!

erikrose left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants