You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@popatam Thanks for putting together the example, it was super helpful for me when using gopy to build wheels for multiple platforms! I refined the workflow you had to be able to build on more Python versions for Mac, as well as armv7l (Raspberry Pi) and Windows (though Windows required me to put in a patch on top of gopy 0.4.5) - workflow example here.
Main finding I had when building on Mac was that the Python versions published on python.org consistently failed to link properly. The Python installs that did work were provided by homebrew. Also, for Windows, the SYSTEMROOT environment variable needs to be passed to the gopy subprocess, otherwise Python fails to start due to errors seeding the interpreter random number generator.
First off, thanks to both of you for writing these workflows, they make bundling bindings into wheels much easier.
@bjia56 I've been trying to get your setup to work with the bindings I'm currently writing. I've got jobs for Linux x64 and aarch64 working, but I can't get Linux armv7l and Windows x64 to pass through pybindgen installation, because of pip which for some reason can't be found. Here's a workflow log for Windows job, and a log for Linux armv7l job, in this one it looks like pip was found and it supposedly installed pybindgen, but Gopy can't find it anywhere.
Also, there is a MacOS x64 job which fails at importing a library, but this might be fixable with LD_LIBRARY_PATH.
It's odd that on Windows, cibuildwheel is pulling down a Python version that doesn't have pip installed. You could add a new subprocess.check_call line that runs python -m ensurepip (use sys.executable instead of just the Python in PATH) and see if that resolves the issue.
For armv7l (and probably all Linux builds), you should use the pip module from the current running Python intepreter (sys.executable). When gopy is invoked, it will use the same Python executable as what is running setup.py. On cibuildwheel, it's possible that their build scripts will symlink the pip in PATH to the pip provided by the current running interpreter, however on my armv7l container there is no such setup and pip (assuming it resolves to /usr/local/bin/pip) is hardcoded to point to 3.8.
fwiw, I haven't tested any of this on gopy 0.4.7 - I have hardcoded my package build to use 0.4.5
Also, originally I tried using Python from sys.executable on all Linux jobs, but I couldn't get pip to run as a module. Here's a log from master branch where it's still how you have it.
ensurepip didn't do a trick, but I was able to finally fix this by switching build frontends to build and adding pybindgen to requires in pyproject.toml.
Something that may help, is a cookiecutter for gopy. I've created one (it isn't perfect, but it is essentially the same code that I'm using for two projects).
Currently, this cookiecutter is cross-platform for macOS and Linux. The build, test, and publishing all works and you can see real examples in the projects below.
Windows
I think the Windows code is quite close. It's commented out at the moment, but I don't believe it'll take much work to complete. Please, if anyone can offer any advice or suggest any changes, I would love to hear any/all ideas. 🙏
Projects based on this structure
My two projects (published to pypi.org) based on the above project structure are here:
Activity
bjia56 commentedon Feb 4, 2023
@popatam Thanks for putting together the example, it was super helpful for me when using gopy to build wheels for multiple platforms! I refined the workflow you had to be able to build on more Python versions for Mac, as well as armv7l (Raspberry Pi) and Windows (though Windows required me to put in a patch on top of gopy 0.4.5) - workflow example here.
Main finding I had when building on Mac was that the Python versions published on python.org consistently failed to link properly. The Python installs that did work were provided by homebrew. Also, for Windows, the
SYSTEMROOTenvironment variable needs to be passed to the gopy subprocess, otherwise Python fails to start due to errors seeding the interpreter random number generator.tfuxu commentedon Aug 24, 2023
First off, thanks to both of you for writing these workflows, they make bundling bindings into wheels much easier.
@bjia56 I've been trying to get your setup to work with the bindings I'm currently writing. I've got jobs for Linux x64 and aarch64 working, but I can't get Linux armv7l and Windows x64 to pass through
pybindgeninstallation, because of pip which for some reason can't be found. Here's a workflow log for Windows job, and a log for Linux armv7l job, in this one it looks like pip was found and it supposedly installedpybindgen, but Gopy can't find it anywhere.Also, there is a MacOS x64 job which fails at importing a library, but this might be fixable with
LD_LIBRARY_PATH.bjia56 commentedon Aug 24, 2023
Hi @tfuxu, some thoughts from my side:
subprocess.check_callline that runspython -m ensurepip(usesys.executableinstead of just the Python in PATH) and see if that resolves the issue.sys.executable). When gopy is invoked, it will use the same Python executable as what is running setup.py. On cibuildwheel, it's possible that their build scripts will symlink the pip in PATH to the pip provided by the current running interpreter, however on my armv7l container there is no such setup andpip(assuming it resolves to/usr/local/bin/pip) is hardcoded to point to 3.8.fwiw, I haven't tested any of this on gopy 0.4.7 - I have hardcoded my package build to use 0.4.5
tfuxu commentedon Aug 24, 2023
Alright thanks, I'll try this.
Also, originally I tried using Python from
sys.executableon all Linux jobs, but I couldn't get pip to run as a module. Here's a log from master branch where it's still how you have it.bjia56 commentedon Aug 24, 2023
That might be the same issue as Windows, so I'd recommend trying ensurepip on all platforms
tfuxu commentedon Aug 25, 2023
ensurepipdidn't do a trick, but I was able to finally fix this by switching build frontends tobuildand addingpybindgentorequiresinpyproject.toml.b-long commentedon Apr 2, 2025
Hi all 👋
Something that may help, is a cookiecutter for gopy. I've created one (it isn't perfect, but it is essentially the same code that I'm using for two projects).
Here's the cookiecutter I built:
macOS and Linux
Currently, this cookiecutter is cross-platform for macOS and Linux. The build, test, and publishing all works and you can see real examples in the projects below.
Windows
I think the Windows code is quite close. It's commented out at the moment, but I don't believe it'll take much work to complete. Please, if anyone can offer any advice or suggest any changes, I would love to hear any/all ideas. 🙏
Projects based on this structure
My two projects (published to pypi.org) based on the above project structure are here:
They are only pushing python 3.11 and 3.12 wheels, but since I'm using Github's matrix style builds, it only takes a line or two change to experiment.
Please feel free to open PRs or experiment with any of the above and please share any experimenting that you do publicly!