internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: cltk/cltk

Issue:
Hyphen added when separating 'ne' enclitics at sentence start
**Describe the bug**
Hyphen added when separating '-ne' enclitics at sentence start

**To Reproduce**
Python 3.9.9; CLTK 1.0.22

```
test = 'nihilne te nocturnum praesidium Palati'
t = LatinWordTokenizer()
print(t.tokenize(test))
```
Current output:
['nihil', '-', '-ne', 'te', 'nocturnum', 'praesidium', 'Palati']

4. See error (include literal copy-paste)

Expected output:
['nihil', '-ne', 'te', 'nocturnum', 'praesidium', 'Palati']

**Desktop (please complete the following information):**
 - MacOS 12.1

**Additional context**
Issue is that there is a redundant hyphen being added in cases where '-ne' is separated as part of the first token in a sentence. I will submit a PR to fix this.



Discussion:

Resolving patch:
diff --git a/src/cltk/tokenizers/lat/lat.py b/src/cltk/tokenizers/lat/lat.py
--- a/src/cltk/tokenizers/lat/lat.py
+++ b/src/cltk/tokenizers/lat/lat.py
@@ -59,6 +59,9 @@ def tokenize(
         >>> toker.tokenize('Cicero dixit orationem pro Sex. Roscio')
         ['Cicero', 'dixit', 'orationem', 'pro', 'Sex.', 'Roscio']
 
+        >>> toker.tokenize('nihilne te nocturnum praesidium Palati')
+        ['nihil', '-ne', 'te', 'nocturnum', 'praesidium', 'Palati']
+
         >>> toker.tokenize('Cenavin ego heri in navi in portu Persico?')
         ['Cenavi', '-ne', 'ego', 'heri', 'in', 'navi', 'in', 'portu', 'Persico', '?']
 
@@ -141,9 +144,7 @@ def replace(matching):
                             else:
                                 specific_tokens += [token[: -len(enclitic)]] + ["est"]
                         else:
-                            specific_tokens += [token[: -len(enclitic)]] + [
-                                "-" + enclitic
-                            ]
+                            specific_tokens += [token]
                         is_enclitic = True
                         break
             if not is_enclitic:


Test patch:
Repository: pypa/cibuildwheel

Issue:
Windows wheels are not built for python 3.7
On Linux wheels are correctly built for all supported python versions. Windows however stops at python 3.6.

Looking at windows.py there seem to be no references to python 3.7


Discussion:

Resolving patch:
diff --git a/cibuildwheel/windows.py b/cibuildwheel/windows.py
--- a/cibuildwheel/windows.py
+++ b/cibuildwheel/windows.py
@@ -40,6 +40,8 @@ def shell(args, env=None, cwd=None):
         PythonConfiguration(version='3.5.x', arch="64", identifier='cp35-win_amd64', path='C:\Python35-x64'),
         PythonConfiguration(version='3.6.x', arch="32", identifier='cp36-win32', path='C:\Python36'),
         PythonConfiguration(version='3.6.x', arch="64", identifier='cp36-win_amd64', path='C:\Python36-x64'),
+        PythonConfiguration(version='3.7.x', arch="32", identifier='cp37-win32', path='C:\Python37'),
+        PythonConfiguration(version='3.7.x', arch="64", identifier='cp37-win_amd64', path='C:\Python37-x64'),
     ]
 
     abs_project_dir = os.path.abspath(project_dir)
@@ -50,6 +52,10 @@ def shell(args, env=None, cwd=None):
         if skip(config.identifier):
             print('cibuildwheel: Skipping build %s' % config.identifier, file=sys.stderr)
             continue
+        
+        # check python & pip exist for this configuration
+        assert os.path.exists(os.path.join(config.path, 'python.exe'))
+        assert os.path.exists(os.path.join(config.path, 'Scripts', 'pip.exe'))
 
         # setup dirs
         if os.path.exists(built_wheel_dir):


Test patch:
Repository: pypa/cibuildwheel

Issue:
'wheel' missing from setup.py install_requires list?
While trying to use a vanilla cibuildwheel configuration with AppVeyor, I kept running into this error,
```
cibuildwheel: Failed to get name of the package. Command was ['c:\\python27\\python.exe', '.\\setup.py', '--name']
```

It was only after running that command (`python .\\setup.py --name`) ahead of the `cibuildwheel --output-dir wheelhouse` that I finally got a clue of what was going on,
```
setup requires that the Python package 'wheel' be installed. Try the command 'pip install wheel'.
```

To resolve this problem I've added `'wheel'` to [setup.py `install_requires` list](https://github.com/joerick/cibuildwheel/blob/master/setup.py#L12) in our fork.

I think that two changes are necessary:
1. On [line 111 of `__main__.py`](https://github.com/joerick/cibuildwheel/blob/master/cibuildwheel/__main__.py#L111), print the **`output`** of [CalledProcessError](https://docs.python.org/2/library/subprocess.html#subprocess.CalledProcessError), and exit with the value of **`returncode`**.
2. Add `'wheel'` to [setup.py `install_requires` list](https://github.com/joerick/cibuildwheel/blob/master/setup.py#L12)

Do you want a PR?


Discussion:
Hey miguelsousa! Thanks for the debugging. Would love a PR for [1] above. Regarding [2], can you see where that error message is coming from? Perhaps there's something about your project's `setup.py` that requires it?

Resolving patch:
diff --git a/cibuildwheel/__main__.py b/cibuildwheel/__main__.py
--- a/cibuildwheel/__main__.py
+++ b/cibuildwheel/__main__.py
@@ -108,9 +108,10 @@ def main():
             print('cibuildwheel: Could not find setup.py at root of project', file=sys.stderr)
             exit(2)
         else:
+            print(err.output)
             print('cibuildwheel: Failed to get name of the package. Command was %s' % err.cmd,
                   file=sys.stderr)
-            exit(2)
+            exit(err.returncode)
 
     if package_name == '' or package_name == 'UNKNOWN':
         print('cibuildwheel: Invalid package name "%s". Check your setup.py' % package_name,


Test patch:
Repository: pypa/cibuildwheel

Issue:
cibuildwheel CI tests failing on Azure for windows
`cibuildwheel` CI tests which are using the sample configuration in README are failing on Windows following Azure update to support python 3.8

Given the number of CI providers now tested, I guess we can try to test `cibuildwheel` on python 2.7, 3.5, 3.6, 3.7 and 3.8 without too much overhead on test time by dispatching the python versions running `cibuildwheel` across CI providers.



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -21,6 +21,8 @@
     package_data={
         'cibuildwheel': ['resources/*'],
     },
+    # Supported python versions
+    python_requires='>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*',
     keywords='ci wheel packaging pypi travis appveyor macos linux windows',
     classifiers=[
         'Intended Audience :: Developers',


Test patch:
diff --git a/unit_test/environment_test.py b/unit_test/environment_test.py
--- a/unit_test/environment_test.py
+++ b/unit_test/environment_test.py
@@ -1,3 +1,4 @@
+import os
 from cibuildwheel.environment import parse_environment
 
 
@@ -37,12 +38,15 @@ def test_inheritance():
 def test_shell_eval():
     environment_recipe = parse_environment('VAR="$(echo "a test" string)"')
 
+    env_copy = os.environ.copy()
+    env_copy.pop('VAR', None)
+
     environment_dict = environment_recipe.as_dictionary(
-        prev_environment={}
+        prev_environment=env_copy
     )
     environment_cmds = environment_recipe.as_shell_commands()
 
-    assert environment_dict == {'VAR': 'a test string'}
+    assert environment_dict['VAR'] == 'a test string'
     assert environment_cmds == ['export VAR="$(echo "a test" string)"']
 
 def test_shell_eval_and_env():
Repository: pypa/cibuildwheel

Issue:
[BUG] Pyproject.toml workaround can make a file
The following pyproject.toml on Windows:

```toml
requires = [
  "setuptools_scm[toml]>=4.1.2"
]
```

produces a file

```
4.1.2
```

which breaks the setuptools_scm versioning, since it's now a dirty directory. Illustrated in #420. I think it used to work originally, as I made a few releases after the Windows 3.5 patch initially went in.

This _only_ breaks if there is a bracketed requirement. 


Discussion:

Resolving patch:
diff --git a/cibuildwheel/windows.py b/cibuildwheel/windows.py
--- a/cibuildwheel/windows.py
+++ b/cibuildwheel/windows.py
@@ -177,8 +177,14 @@ def pep_518_cp35_workaround(package_dir: Path, env: Dict[str, str]) -> None:
             if 'build-system' in data
             else []
         )
+
         if requirements:
-            shell(['pip', 'install'] + requirements, env=env)
+            with tempfile.TemporaryDirectory() as d:
+                reqfile = Path(d) / "requirements.txt"
+                with reqfile.open("w") as f:
+                    for r in requirements:
+                        print(r, file=f)
+                call(['pip', 'install', '-r', reqfile], env=env)
 
 
 def build(options: BuildOptions) -> None:


Test patch:
diff --git a/test/test_pep518.py b/test/test_pep518.py
--- a/test/test_pep518.py
+++ b/test/test_pep518.py
@@ -1,6 +1,7 @@
 import textwrap
 from . import test_projects
 from . import utils
+import os
 
 basic_project = test_projects.new_c_project(
     setup_py_add=textwrap.dedent(
@@ -27,6 +28,7 @@
 [build-system]
 requires = [
     "setuptools >= 42",
+    "setuptools_scm[toml]>=4.1.2",
     "wheel",
     "requests==2.22.0; python_version<'3.6'",
     "requests==2.23.0; python_version>='3.6'"
@@ -47,3 +49,10 @@ def test_pep518(tmp_path):
     # check that the expected wheels are produced
     expected_wheels = utils.expected_wheels("spam", "0.1.0")
     assert set(actual_wheels) == set(expected_wheels)
+
+    # These checks ensure an extra file is not created when using custom
+    # workaround; see https://github.com/joerick/cibuildwheel/issues/421
+    assert not (project_dir / "42").exists()
+    assert not (project_dir / "4.1.2").exists()
+
+    assert len(os.listdir(project_dir)) == len(basic_project.files)
Repository: pypa/cibuildwheel

Issue:
set MACOSX_DEPLOYMENT_TARGET for all stages?
I recently adopted cibuildwheel (it is wonderful, thank you!), and made a broken release on older macs. The mistake I made was failing to set MACOSX_DEPLOYMENT_TARGET for the CIBW_BEFORE_ALL stage. I was surprised to see that CIBW has the feature to set MACOSX_DEPLOYMENT_TARGET, but doesn't do it for all stages.

#306 sets MACOSX_DEPLOYMENT_TARGET for python commands, but I was building a library dependency in CIBW_BEFORE_ALL.

My wheels are roughly:

- CIBW_BEFORE_ALL compiles and installs a library
- build my wheel that links the library
- repair (auditwheel/delocate/delvewheel) bundles the library in the wheel


So my question is: should I have built the library in a different stage, or does it make sense to set the default MACOSX_DEPLOYMENT_TARGET for all commands, not just the python environment?

Fixing it was easy enough (set MACOSX_DEPLOYMENT_TARGET in global env)


Discussion:
Ah, I see. Yes the BEFORE_ALL commands on macOS and Windows run outside of a cibuildwheel Python environment, so we haven't set our environment variables yet. 

Your workflow sounds sensible to me. (The only snag I can think of will be that once `universal2` is supported (#484), you'll have to build your shared lib as universal2, also. But I think delocate should be able to handle it)

I'm not sure that we've built-in the assumption that BEFORE_ALL is for _building_ dependencies exactly, but, it does seem pretty harmless to add `env.setdefault('MACOSX_DEPLOYMENT_TARGET', '10.9')` there. The other question we could consider, is 'should we run the macos BEFORE_ALL inside one of our Python environments, rather than in the system environment?' We do that on Linux, but that was only because the system Python on `manylinux `was 2.6 or something ancient.

But it's probably easier to do the simple thing - adding `env.setdefault('MACOSX_DEPLOYMENT_TARGET', '10.9')` before calling BEFORE_ALL.

`env.setdefault('MACOSX_DEPLOYMENT_TARGET', '10.9')` would still provide strange behavior if someone set `CIBW_ENVIRONMENT: MACOSX_DEPLOYMENT_TARGET=10.14` (say, for C++17 support)? Seems like the correct thing would be to match Linux on Windows/macOS and make the environment affect all steps, since it already does that on Linux? We need to be careful not to override `MACOSX_DEPLOYMENT_TARGET` - most projects _should_ be setting it, really, for constancy and control, but many don't.

Resolving patch:
diff --git a/cibuildwheel/macos.py b/cibuildwheel/macos.py
--- a/cibuildwheel/macos.py
+++ b/cibuildwheel/macos.py
@@ -288,6 +288,7 @@ def build(options: BuildOptions) -> None:
         if options.before_all:
             log.step('Running before_all...')
             env = options.environment.as_dictionary(prev_environment=os.environ)
+            env.setdefault('MACOSX_DEPLOYMENT_TARGET', '10.9')
             before_all_prepared = prepare_command(options.before_all, project='.', package=options.package_dir)
             call([before_all_prepared], shell=True, env=env)
 


Test patch:
Repository: pypa/cibuildwheel

Issue:
Travis ppc64le network issue work-around
### Description

Hi,

I currently see network issues with docker containers on Travis CI ppc64le builders.
Essentially, connections seem to time out, e.g., on `yum update`.

The same problem seems to be known in conda-forge and adding `--network=host` to `docker run` seems to solve the issue.

Do you know how I can most simply apply the same work-around in cibuildwheel?

X-ref:
- https://github.com/conda-forge/conda-smithy/pull/1520

### Build log

X-ref:
- https://github.com/openPMD/openPMD-api/pull/1136

### CI config

- https://github.com/openPMD/openPMD-api/tree/wheels


Discussion:

Resolving patch:
diff --git a/cibuildwheel/docker_container.py b/cibuildwheel/docker_container.py
--- a/cibuildwheel/docker_container.py
+++ b/cibuildwheel/docker_container.py
@@ -1,6 +1,7 @@
 import io
 import json
 import os
+import platform
 import shlex
 import subprocess
 import sys
@@ -9,6 +10,8 @@
 from types import TracebackType
 from typing import IO, Dict, List, Optional, Sequence, Type, cast
 
+from cibuildwheel.util import CIProvider, detect_ci_provider
+
 from .typing import PathOrStr, PopenBytes
 
 
@@ -44,6 +47,15 @@ def __init__(
     def __enter__(self) -> "DockerContainer":
         self.name = f"cibuildwheel-{uuid.uuid4()}"
         cwd_args = ["-w", str(self.cwd)] if self.cwd else []
+
+        # work-around for Travis-CI PPC64le Docker runs since 2021:
+        # this avoids network splits
+        # https://github.com/pypa/cibuildwheel/issues/904
+        # https://github.com/conda-forge/conda-smithy/pull/1520
+        network_args = []
+        if detect_ci_provider() == CIProvider.travis_ci and platform.machine() == "ppc64le":
+            network_args = ["--network=host"]
+
         shell_args = ["linux32", "/bin/bash"] if self.simulate_32_bit else ["/bin/bash"]
         subprocess.run(
             [
@@ -53,6 +65,7 @@ def __enter__(self) -> "DockerContainer":
                 f"--name={self.name}",
                 "--interactive",
                 "--volume=/:/host",  # ignored on CircleCI
+                *network_args,
                 *cwd_args,
                 self.docker_image,
                 *shell_args,


Test patch:
Repository: pypa/cibuildwheel

Issue:
on windows, setup_py_python_requires attempts to open utf-8 setup.py as Windows-1252 and fails
### Description

This [setup.py file](https://github.com/fgregg/fastcluster/blob/master/setup.py) is valid utf-8, and has a few non-ascii characters. In a windows build, `setup_py_python_requires` appears to be opening this file as if it was encoded like Windows-1252 and thus fails on some non-ascii characters.

### Build log

https://github.com/fgregg/fastcluster/runs/4660766954?check_suite_focus=true#step:5:40

### CI config

https://github.com/fgregg/fastcluster/blob/master/.github/workflows/pythonpackage.yml#L41-L47


Discussion:

Resolving patch:
diff --git a/cibuildwheel/projectfiles.py b/cibuildwheel/projectfiles.py
--- a/cibuildwheel/projectfiles.py
+++ b/cibuildwheel/projectfiles.py
@@ -70,7 +70,7 @@ def get_requires_python_str(package_dir: Path) -> Optional[str]:
         pass
 
     try:
-        with (package_dir / "setup.py").open() as f2:
+        with (package_dir / "setup.py").open(encoding="utf8") as f2:
             return setup_py_python_requires(f2.read())
     except FileNotFoundError:
         pass


Test patch:
diff --git a/unit_test/projectfiles_test.py b/unit_test/projectfiles_test.py
--- a/unit_test/projectfiles_test.py
+++ b/unit_test/projectfiles_test.py
@@ -25,7 +25,7 @@ def test_read_setup_py_simple(tmp_path):
 
 
 def test_read_setup_py_full(tmp_path):
-    with open(tmp_path / "setup.py", "w") as f:
+    with open(tmp_path / "setup.py", "w", encoding="utf8") as f:
         f.write(
             dedent(
                 """
@@ -35,6 +35,7 @@ def test_read_setup_py_full(tmp_path):
 
                 setuptools.setup(
                     name = "hello",
+                    description = "≥“”ü",
                     other = 23,
                     example = ["item", "other"],
                     python_requires = "1.24",
@@ -43,7 +44,9 @@ def test_read_setup_py_full(tmp_path):
             )
         )
 
-    assert setup_py_python_requires(tmp_path.joinpath("setup.py").read_text()) == "1.24"
+    assert (
+        setup_py_python_requires(tmp_path.joinpath("setup.py").read_text(encoding="utf8")) == "1.24"
+    )
     assert get_requires_python_str(tmp_path) == "1.24"
Repository: pypa/cibuildwheel

Issue:
[Docs] Example may accidentally be encouraging users to write invalid `pyproject.toml` files
### Description

Hi guys, first of all thank you for the amazing project (always good to remember).

While I was working on adding support for PEP 621 to setuptools, I noticed a series of users having problems with invalid `pyproject.toml` files. The common pattern seem to be a almost empty `[project]` table with only a `requires-python` field set, which is invalid according to PEP 621.

It took me some time to find the reason for this behaviour but I think it comes from:
https://cibuildwheel.readthedocs.io/en/stable/options/#requires-python

I suspect that the example and notes about the preferred way of setting the config has been encouraging users that are unaware of PEP 621 to write technically invalid `pyproject.toml` files.

Please note that this issue is not necessarily related to setuptools itself.
The existence of the `[project]` table in the `pyproject.toml` allows (according to the standard) the installer/builder/consumer program to treat the package differently (specially regarding `dynamic`).

I think it would be nice to at least add a note about this so users became aware of the implications of adding a `[project]` table.

### Build log

_No response_

### CI config

_No response_


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -4,6 +4,7 @@
     "docs": [
         "mkdocs-include-markdown-plugin==2.8.0",
         "mkdocs==1.0.4",
+        "jinja2==3.0.3",
         "pymdown-extensions",
         "mkdocs-macros-plugin",
     ],


Test patch:
Repository: pypa/cibuildwheel

Issue:
When testing x86_64 on macOS arm64, `CIBW_TEST_COMMAND` isn't ran under Rosetta when using pipes
### Description

So basically, the problem is that the way cibuildwheel runs stuff under Rosetta is by prefixing the command with `arch -x86_64`. This works great for regular subprocess calls *but* when used with `shell=True`, it only prefixes the first command with it:
https://github.com/pypa/cibuildwheel/blob/fb63392538402c77b519160b7af87b37e66d98c6/cibuildwheel/macos.py#L497-L508

So when `CIBW_TEST_COMMAND` is set to something like `false || python -c 'import spam'`, it doesn't work because the latter part of the command isn't run under Rosetta:
```
+ arch -x86_64 false || python -c 'import spam'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: dlopen(/private/var/folders/0d/08wbx2j52nx5hjg16cshb8g80000gn/T/cibw-run-qbqflk30/cp39-macosx_x86_64/venv-test/lib/python3.9/site-packages/spam.cpython-39-darwin.so, 0x0002): tried: '/private/var/folders/0d/08wbx2j52nx5hjg16cshb8g80000gn/T/cibw-run-qbqflk30/cp39-macosx_x86_64/venv-test/lib/python3.9/site-packages/spam.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e)))
```

I'm unsure how this should be resolved, perhaps we should have a simple python script that can run shell commands? Then it would be possible to do `arch -x86_64 python -m cibuildwheel._run_shell_command "false || python -c 'import spam'"` and I think Rosetta emulation would then apply to everything that's run there?

---

The linked build log and CI config are for Cirrus CI which I'm adding support for in #1191 as this is the only available CI that has M1 runners and I don't have any macOS system myself. The issue is not related to the used CI service at all though so that should not matter here.

### Build log

https://cirrus-ci.com/task/4706399904071680?logs=run_cibuildwheel#L660

### CI config

https://raw.githubusercontent.com/jack1142/cibuildwheel/25d1b927d828047928aea2c6fb7e9dd0eab42fc8/.cirrus.yml


Discussion:
Ah yes, good catch! It looks to me that the solution could be

https://github.com/pypa/cibuildwheel/blob/fb63392538402c77b519160b7af87b37e66d98c6/cibuildwheel/macos.py#L508

```
                    shell_with_arch = functools.partial(call, *arch_prefix, "sh", "-c")
```

Resolving patch:
diff --git a/cibuildwheel/macos.py b/cibuildwheel/macos.py
--- a/cibuildwheel/macos.py
+++ b/cibuildwheel/macos.py
@@ -505,7 +505,7 @@ def build(options: Options, tmp_path: Path) -> None:
 
                     # define a custom 'call' function that adds the arch prefix each time
                     call_with_arch = functools.partial(call, *arch_prefix)
-                    shell_with_arch = functools.partial(shell, *arch_prefix)
+                    shell_with_arch = functools.partial(call, *arch_prefix, "/bin/sh", "-c")
 
                     # Use --no-download to ensure determinism by using seed libraries
                     # built into virtualenv


Test patch:
Repository: pypa/cibuildwheel

Issue:
--only doesn't work for `-win32` identifiers
> - cp311 https://github.com/ddelange/asyncpg/actions/runs/3092263953/jobs/5003341864#step:4:43
> - same for all other win32 builds: `Invalid --only='cp310-win32', must be a build selector with a known platform`
> 
> in https://github.com/ddelange/asyncpg/pull/2
> 
> and before this change it was fine: https://github.com/ddelange/asyncpg/actions/runs/3072698535/jobs/4964355341#step:4:89
> 
> maybe it's an issue with the `--only` flag?
> 
> on my mac:
> 
> ```console
> $ cibuildwheel --print-build-identifiers --platform windows --arch x86,AMD64
> cp36-win32
> cp36-win_amd64
> cp37-win32
> cp37-win_amd64
> cp38-win32
> cp38-win_amd64
> cp39-win32
> cp39-win_amd64
> cp310-win32
> cp310-win_amd64
> cp311-win32
> cp311-win_amd64
> pp37-win_amd64
> pp38-win_amd64
> pp39-win_amd64
> ```
> 

_Originally posted by @ddelange in https://github.com/pypa/cibuildwheel/issues/1266#issuecomment-1252703994_
      


Discussion:
Issue seems to be this line:

https://github.com/mayeut/cibuildwheel/blob/6df5de717552b07dfee43760b154f0bf8a1af4ed/cibuildwheel/__main__.py#L176

Resolving patch:
diff --git a/cibuildwheel/__main__.py b/cibuildwheel/__main__.py
--- a/cibuildwheel/__main__.py
+++ b/cibuildwheel/__main__.py
@@ -173,7 +173,7 @@ def build_in_directory(args: CommandLineArguments) -> None:
             platform = "linux"
         elif "macosx_" in args.only:
             platform = "macos"
-        elif "win_" in args.only:
+        elif "win_" in args.only or "win32" in args.only:
             platform = "windows"
         else:
             print(


Test patch:
diff --git a/unit_test/main_tests/main_platform_test.py b/unit_test/main_tests/main_platform_test.py
--- a/unit_test/main_tests/main_platform_test.py
+++ b/unit_test/main_tests/main_platform_test.py
@@ -199,6 +199,7 @@ def test_archs_platform_all(platform, intercepted_build_args, monkeypatch):
     (
         ("cp311-manylinux_x86_64", "linux"),
         ("cp310-win_amd64", "windows"),
+        ("cp310-win32", "windows"),
         ("cp311-macosx_x86_64", "macos"),
     ),
 )