Skip to content
This repository has been archived by the owner on Aug 30, 2024. It is now read-only.

fixup readme, add manylinux1 wheels #79

Merged
merged 3 commits into from
Apr 23, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 17 additions & 28 deletions README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -34,52 +34,41 @@ 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 manylinux standard.

The ``.travis.yml`` file in this repository has a line containing the API key
for the Rackspace container 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 the Rackspace
directory pointed to by http://wheels.scipy.org.
The ``azure/*`` files in this repository read a token stored in the Azure
Pipeline used to run the CI. This encrypted key gives Azure permission to
upload to the ananconda.org directories ``https://anaconda.org/<user>/numpy/``
where user is the ``ANACONDA_ORG`` value in the ``yml`` files.

Triggering a build
==================

You will likely want to edit the ``.travis.yml`` and ``appveyor.yml`` files to
You will likely want to edit the ``azure/*`` files to
specify the ``BUILD_COMMIT`` before triggering a build - see below.

You will need write permission to the github repository to trigger new builds
on the travis-ci interface. Contact us on the mailing list if you need this.
You will need write permission to the github repository to trigger new builds.
Contact us on the mailing list if you need this.

You can trigger a build by:

* making a commit to the `numpy-wheels` repository (e.g. with `git
commit --allow-empty`); or
* clicking on the circular arrow icon towards the top right of the travis-ci
page, to rerun the previous build.

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.
* merging a pull request to the repo

Which numpy commit does the repository build?
===============================================

The `numpy-wheels` repository will build the commit specified in the
``BUILD_COMMIT`` at the top of the ``.travis.yml`` and ``appveyor.yml`` files.
This can be any naming of a commit, including branch name, tag name or commit
hash.
PRs merged to this repo from a fork, and commits directly pushed to this repo
will build the commit specified in the ``BUILD_COMMIT`` at the top of the
``azure/windows.yml`` and ``azure/posix.yml`` files, the wheels will be
uploaded to https://anaconda.org/multibuild-wheels-staging/numpy. The
``NIGHTLY_BUILD_COMMIT`` is built once a week (sorry for the misnomer),
and uploaded to https://anaconda.org/scipy-wheels-nightly/.
The value of ``BUILD_COMMIT`` can be any naming of a commit, including branch
name, tag name or commit hash.

Uploading the built wheels to pypi
==================================

Be careful, http://wheels.scipy.org points to a container on a distributed
content delivery network. It can take up to 15 minutes for the new wheel file
to get updated into the container at http://wheels.scipy.org.

The same contents appear at
https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com;
you might prefer this address because it is https.

When the wheels are updated, you can download them to your machine manually,
and then upload them manually to pypi, or by using twine_. You can also use a
script for doing this, housed at :
Expand All @@ -92,7 +81,7 @@ You will typically have a directory on your machine where you store wheels,
called a `wheelhouse`. The typical call for `wheel-uploader` would then
be something like::

CDN_URL=https://3f23b170c54c2533c070-1c8a9b3114517dc5fe17b7c3f8c63a43.ssl.cf2.rackcdn.com
CDN_URL=https://anaconda.org/multibuild-wheels/staging/numpy/files
wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t macosx numpy 1.11.1
wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t manylinux1 numpy 1.11.1
wheel-uploader -r warehouse -u $CDN_URL -s -v -w ~/wheelhouse -t win numpy 1.11.1
Expand Down
25 changes: 25 additions & 0 deletions azure-pipelines.yml
Original file line number Diff line number Diff line change
Expand Up @@ -76,6 +76,31 @@ jobs:
py_3.8_64:
MB_PYTHON_VERSION: "3.8"
MB_ML_VER: "2010"
# manylinux1 wheels
py_3.6_32manylinux1:
MB_PYTHON_VERSION: "3.6"
PLAT: "i686"
MB_ML_VER: "1"
ENV_VARS_PATH: "env_vars_32.sh"
py_3.6_64manylinux1:
MB_PYTHON_VERSION: "3.6"
MB_ML_VER: "1"
py_3.7_32manylinux1:
MB_PYTHON_VERSION: "3.7"
PLAT: "i686"
MB_ML_VER: "1"
ENV_VARS_PATH: "env_vars_32.sh"
py_3.7_64manylinux1:
MB_PYTHON_VERSION: "3.7"
MB_ML_VER: "1"
py_3.8_32manylinux1:
MB_PYTHON_VERSION: "3.8"
PLAT: "i686"
MB_ML_VER: "1"
ENV_VARS_PATH: "env_vars_32.sh"
py_3.8_64manylinux1:
MB_PYTHON_VERSION: "3.8"
MB_ML_VER: "1"

- template: azure/posix.yml
parameters:
Expand Down
2 changes: 1 addition & 1 deletion azure/posix.yml
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ jobs:
vmImage: ${{ parameters.vmImage }}
variables:
REPO_DIR: "numpy"
BUILD_COMMIT: 'v1.18.3'
BUILD_COMMIT: 'f1be9e50ff' # needed for 32 bit builds, should become 1.18.4
PLAT: "x86_64"
CYTHON_BUILD_DEP: "cython==0.29.16"
NIGHTLY_BUILD_COMMIT: "master"
Expand Down