Daily numpy wheel builds - prefer to per-commit builds?
Hi, I've been working to get daily travis-ci cron-job manylinux builds working for numpy and scipy wheels. They are now working OK: https://travis-ci.org/MacPython/numpy-wheels https://travis-ci.org/MacPython/scipy-wheels https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcd... These are daily builds of the respective numpy and scipy master branches. Numpy already has a system, kindly worked up by Olivier Grisel, which uploads wheel builds from each travis-ci run. travis-ci uploads these wheels for every commit, at the "travis-dev-wheels" container on Rackspace, visible at https://f66d8a5767b134cb96d3-4ffdece11fd3f72855e4665bc61c7445.ssl.cf2.rackcd... . These builds are specific to the Linux they were built on - in this case Ubuntu 12.04. Some projects use these per-commit builds for testing compatibility with development Numpy code. Now I'm wondering what the relationship should be between the current every-commit builds and the new wheel builds. I think that we should prefer the new wheel builds and deprecate the previous per-commit builds, because: * the new manylinux wheels are self-contained, and so can be installed with pip without extra lines of `apt` installs; * the manylinux builds work on any travis container, not just the current 12.04 container; * manylinux builds should be faster, as they are linked against OpenBLAS; * manylinux wheels are closer to the wheels we distribute for releases, and therefore more useful for testing against. What do y'all think? Cheers, Matthew
On Tue, Feb 28, 2017 at 9:43 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
I've been working to get daily travis-ci cron-job manylinux builds working for numpy and scipy wheels. They are now working OK:
https://travis-ci.org/MacPython/numpy-wheels https://travis-ci.org/MacPython/scipy-wheels https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a 83.ssl.cf2.rackcdn.com
These are daily builds of the respective numpy and scipy master branches.
Numpy already has a system, kindly worked up by Olivier Grisel, which uploads wheel builds from each travis-ci run. travis-ci uploads these wheels for every commit, at the "travis-dev-wheels" container on Rackspace, visible at https://f66d8a5767b134cb96d3-4ffdece11fd3f72855e4665bc61c74 45.ssl.cf2.rackcdn.com . These builds are specific to the Linux they were built on - in this case Ubuntu 12.04.
Some projects use these per-commit builds for testing compatibility with development Numpy code.
Now I'm wondering what the relationship should be between the current every-commit builds and the new wheel builds.
I think that we should prefer the new wheel builds and deprecate the previous per-commit builds, because:
* the new manylinux wheels are self-contained, and so can be installed with pip without extra lines of `apt` installs; * the manylinux builds work on any travis container, not just the current 12.04 container; * manylinux builds should be faster, as they are linked against OpenBLAS; * manylinux wheels are closer to the wheels we distribute for releases, and therefore more useful for testing against.
What do y'all think?
Uploading your daily Linux and OS X builds and just turning off uploads of the per-commit builds sounds like an improvement to me. Ralf
+1 as well. -- Olivier
participants (3)
-
Matthew Brett
-
Olivier Grisel
-
Ralf Gommers