arm64-only wheel is incorrectly marked as universal2

[youchangkim]

What version of OR-Tools and what language are you using?
Version: v9.4.1874
Language: Python

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)
CP-SAT

What operating system (Linux, Windows, ...) and version?
macOS-11 + x86_64

What did you do?

1. Install ortools 9.4.18742.
2. Run cp_sat_example.py (https://github.com/google/or-tools/blob/stable/ortools/sat/samples/cp_sat_example.py)

What did you expect to see

Maximum of objective function: 35.0

x = 7
y = 3
z = 5

Statistics
  status   : OPTIMAL
  conflicts: 0
  branches : 0
  wall time: 0.014359 s

What did you see instead?

Traceback (most recent call last):
  File "sat.py", line 18, in <module>
    from ortools.sat.python import cp_model
  File "[DETACHED]/venv/lib/python3.8/site-packages/ortools/sat/python/cp_model.py", line 55, in <module>
    from ortools.sat.python import swig_helper
ImportError: dlopen([DETACHED]/venv/lib/python3.8/site-packages/ortools/sat/python/swig_helper.so, 2): no suitable image found.  Did find:
	[DETACHED]/venv/lib/python3.8/site-packages/ortools/sat/python/swig_helper.so: mach-o, but wrong architecture
	[DETACHED]/venv/lib/python3.8/site-packages/ortools/sat/python/swig_helper.so: mach-o, but wrong architecture

Make sure you include information that can help us debug (full error message, model Proto).

Anything else we should know about your project / environment

[Mizux]

DevNote:

1. On my M1 when I built the python packages they generate macosx_11_0_universal2.whl wheel packages (note: I've used homebrew silicon python package as runtime)
2. On my gMac (intel) i've use python installer from python.org and it has generated macosx_10_15_x86_64.whl wheel package.

-> I need to find a way to generate macosx_*_arm64.whl package on M1 thus intel mac won't try to use universal2 (M1 only ) package...

To Test(mizux):

• try to rename the universal2 package on M1 and see if we can still upload them on pypi.org
• try to install a python interpreter coming from python.org instead (may tag wheel package as arm64 instead of universal2)
• Look at pypa setup.py bdist source code to see if there is an option we can pass/set directly in the setup.py to corectly tag the package...

[youchangkim]

Possibly related issue: pypa/wheel#406.

It'd be great if you can yank current release and re-upload by changing _universal2.whl to _arm64.whl.

[Mizux]

Seems a rename of the file would be enough according to
https://github.com/grpc/grpc/pull/29857/files#diff-b995ed392ef9bb7553c8179cb376ad64c2d2ddbec88122bce29d5896e5fc9f0cR147-R164

For yanking, need to think of it, could be a good alternative since we can't remove some uploaded package...
EDIT: seems I can remove some wheel packages among the list so I could try to remove all universal2 packages and reupload them with x86_64/arm64 suffix...

[Mizux]

Just reuploaded wheel packages with the correct suffix...

EDIT: just tested (using a venv) on Apple Intel and M1 seems to work...
note: dist-info/WHEEL metadata still contains tag universal2 -> need to find a way to correct it for the next release