Python shared library loading is broken on MacOS

[acruise]

When I install regopy in my project, on an Intel mac, it drops both Linux and MacOS shared libraries:

$ ls -lart .venv/lib/python3.12/site-packages/regopy/librego_shared*
-rwxr-xr-x   1 alex  staff  14628328 Oct 27 10:30 librego_shared.dylib
-rwxr-xr-x   1 alex  staff  11993784 Oct 27 10:30 librego_shared.so

Unfortunately, in this code, regopy tries to load the .so file just because it exists, rather than checking which OS it's running on first, so I get this delightfully Google-sparse error message:

OSError: dlopen(.../.venv/lib/python3.12/site-packages/regopy/librego_shared.so, 0x0006): tried: '.../.venv/lib/python3.12/site-packages/regopy/librego_shared.so' (slice is not valid mach-o file), '/System/Volumes/Preboot/Cryptexes/OS/.../.venv/lib/python3.12/site-packages/regopy/librego_shared.so' (no such file), '.../.venv/lib/python3.12/site-packages/regopy/librego_shared.so' (slice is not valid mach-o file)

[matajoh]

Ah, my apologies. I did not intend to break Intel Mac support in this way. I need to add back in an Intel image for macos tests to my Github workflow. I'll do that, and then review your PR. Thanks!

[matajoh]

So digging into this today has been fascinating. I was able to repro this behaviour, but only when doing a pip install from the sdist, as you've done. If I build on MacOS x86_64 from within the repo, then it only builds the dylib and everything works correctly. It is not clear at all why in the sdist scenario it builds both. Your proposed PR will address the issue, but in a sense it is just a patch over a much stranger behaviour.