We automate wheel building using this custom github repository that builds on the travis-ci OSX machines and the travis-ci Linux machines.
The travis-ci interface for the builds is https://travis-ci.org/bashtage/arch-wheels
The driving github repository is https://github.com/bashtage/arch-wheels
The wheel-building repository:
repair
(Manylinux1). delocate
and auditwheel
copy the required dynamic libraries into the wheel and relinks the extension modules against the copied libraries;The resulting wheels are therefore self-contained and do not need any external dynamic libraries apart from those provided as standard by OSX / Linux as defined by the manylinux1 standard.
The .travis.yml
file in this repository has a line containing the login for Test PyPi encrypted with an RSA key that is unique to the repository - see http://docs.travis-ci.com/user/encryption-keys. This encrypted key gives the travis build permission to upload to test PyPi.
You will likely want to edit the .travis.yml
file to specify the BUILD_COMMIT
before triggering a build - see below.
You can trigger a build by:
In general, it is better to trigger a build with a commit, because this makes a new set of build products and logs, keeping the old ones for reference. Keeping the old build logs helps us keep track of previous problems and successful builds.
The arch-wheels repository will build the commit specified in the BUILD_COMMIT
at the top of the .travis.yml
file. This can be any naming of a commit, including branch name, tag name or commit hash.
Wheels are are automatically uploaded using twine.
Of course, you will need permissions to upload to PyPI, for this to work.
git submodule update --remote --merge
False
)True
, PyPi to False
)False
)