Skip to content

Conversation

@lazka
Copy link
Contributor

@lazka lazka commented Apr 17, 2025

Since GitHub Actions now has ARM64 Windows runners we can test and build natively.

  • Python ARM64 builds are only available since 3.11, so skip older versions for ARM64 everywhere.
  • Sodium has arm64 builds only in a later binary release, so update the tarball. Downloaded from here: https://download.libsodium.org/libsodium/releases/
  • The arm64 sodium builds are only available for v143, so just bump to v143 everywhere to keep things simple.

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

I'm feeling very uneasy updating a binary blob in a PR, so ideally I shouldn't be trusted with this.

I could download minisign there, verify its checksum, and then use it to verify the libsodium release. And in addition a maintainer should also verify. Or a maintainer could re-do this PR. Thoughts on this?

@echoix
Copy link

echoix commented Apr 17, 2025

Isn't changing the MSVC version quite a big change to be slipped in a PR adding Windows arm64 builds? It wouldn't be my instinct to expect a problem coming from here when reading release notes/commits.

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

I'm happy to limit that MSVC change to arm64 if wanted. Or split the MSVC change out into its own PR.

I had hoped that running the test would rule out any issues this could generate, but I'm lacking experience there.

@reaperhulk
Copy link
Member

I think I probably need to go ahead and do a PR to update to the latest 1.0.20-stable and also add the arm64 static lib at the same time. I'm comfortable with the switch to later MSVC though (since this is all ucrt anyway).

I'm swamped for a variety of reasons but this should be some pretty simple work so I'll try to get to it ASAP so you can rebase and add the actual win arm64 build (if you're interested).

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

Sounds good. Just ping me if needed.

Regarding MSVC version, I noticed that in the wheel build it is explicitly selected via VsDevCmd.bat, but during testing I don't see anything like that. Does that mean setuptools will just use the newest one right now?

@reaperhulk
Copy link
Member

Is it? I think we just set x64/x86 using vsdevcmd? I believe that does default to x64 in the actions environment.

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

I don't see anything here:

windows:
runs-on: windows-latest
strategy:
matrix:
WINDOWS:
- {ARCH: 'x86', SODIUM_ARCH: 'Win32'}
- {ARCH: 'x64', SODIUM_ARCH: 'x64'}
PYTHON:
- {VERSION: "3.7", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.8", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.9", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.10", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.11", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.12", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
- {VERSION: "3.13", NOXSESSION: "tests", SODIUM_MSVC_VERSION: "v142"}
name: "Windows ${{ matrix.WINDOWS.ARCH }} ${{ matrix.PYTHON.VERSION }} ${{ matrix.PYTHON.NOXSESSION }}"
steps:
- uses: actions/[email protected]
- name: Setup python
uses: actions/setup-python@v5
with:
python-version: ${{ matrix.PYTHON.VERSION }}
architecture: ${{ matrix.WINDOWS.ARCH }}
- name: 'Extract libsodium libraries'
run: |
Expand-Archive src/libsodium-1.0.20-stable-msvc.zip -DestinationPath c:\
shell: powershell
- name: Install nox and coverage
run: pip install nox coverage
- name: Run tests
run: |
set PYNACL_SODIUM_LIBRARY_NAME=sodium
set PYNACL_SODIUM_STATIC=1
set SODIUM_INSTALL=system
set INCLUDE=C:/libsodium/include;%INCLUDE%
set LIB=C:/libsodium/${{ matrix.WINDOWS.SODIUM_ARCH }}/release/${{ matrix.PYTHON.SODIUM_MSVC_VERSION }}/static;%LIB%
nox -s ${{ matrix.PYTHON.NOXSESSION }}
IF %ERRORLEVEL% NEQ 0 EXIT /B %ERRORLEVEL%
shell: cmd
- name: Upload coverage
run: |
curl -o codecov.sh -f https://codecov.io/bash || curl -o codecov.sh -f https://codecov.io/bash || curl -o codecov.sh -f https://codecov.io/bash || curl -o codecov.sh -f https://codecov.io/bash || curl -o codecov.sh -f https://codecov.io/bash
bash codecov.sh -n "Python ${{ matrix.PYTHON.VERSION }} on Windows ${{ matrix.WINDOWS.ARCH }}"

though I might be missing something

@lazka lazka force-pushed the win-arm64-wheels branch from e05c074 to a9fee3f Compare April 17, 2025 21:46
@reaperhulk
Copy link
Member

In the wheel builder we set x86/x64 but we don't set MSVC version. In standard CI we don't set anything because setuptools actually handles this properly automatically these days -- we could almost certainly remove it on the wheel builder side.

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

hm, I thought the compiler for the extension has to match the compiler used for building the static libsodium library, something setuptools can't know about.

@lazka lazka force-pushed the win-arm64-wheels branch from a9fee3f to cde2192 Compare April 17, 2025 21:53
@reaperhulk
Copy link
Member

That was a hard requirement with MSVC and Python until the advent of the ucrt. These days you can have some amount of mismatch (see: https://wiki.python.org/moin/WindowsCompilers). Basically all 14.x are compatible, which started with Visual Studio 2015.

@lazka
Copy link
Contributor Author

lazka commented Apr 17, 2025

I meant the compatibility of static linking in a library into an extension, not the compatibility between the resulting extension and CPython. But maybe that's also not an issue anymore. I remember having errors due to that in pycairo some years ago.

@reaperhulk
Copy link
Member

Okay we've updated to latest 1.0.20-stable and updated the msvc zip, so this can be rebased without that task now.

lazka added 3 commits April 22, 2025 19:59
libsodium provides v143 builds (built with Visual Studio 2022)
so we can use them and switch to building with VS2022 instead
of VS2019.

This will be helpful for future arm64 builds since libsodium only
provides v143 arm64 binaries.

While at it, make sure that "VsDevCmd.bat" is also called in the
test job and not just in the wheel build job, to make sure that
the same compiler setup is used in both places.
GitHub now provides native arm64 windows runners using the
"windows-11-arm" image, so we can easily add it to the test matrix.

Python ARM64 builds are only available since 3.11, so only test with
Python 3.11 to 3.13.

The arm64 libsodium binaries have been added with c5253ad
Use the new native "windows-11-arm" Windows arm64 image for building.

Since arm64 Python is only available as of Python 3.11, use that for
building instead of 3.9, which is used for the other arches.
@lazka lazka force-pushed the win-arm64-wheels branch from cde2192 to d68ad7d Compare April 22, 2025 18:03
@lazka
Copy link
Contributor Author

lazka commented Apr 22, 2025

Thanks!

I split it up into three separate commits while at it. See the commit messages for details.

@reaperhulk
Copy link
Member

reaperhulk commented Apr 22, 2025

Hmm, we should likely also move to abi3 builds but I can look at that in a different PR.

Edit: Having a baby has melted my brain, we've done abi3 here for years.

@reaperhulk reaperhulk merged commit 96a9f56 into pyca:main Apr 22, 2025
49 checks passed
@lazka
Copy link
Contributor Author

lazka commented Apr 22, 2025

Thanks!

@khmyznikov
Copy link

Great work! When it will be available on PyPi?

@reaperhulk
Copy link
Member

No specific timeline, but I will try to get a release out soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants