Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travis: switch to trusty, pip and libc++ caching, pypy numpy #798

Merged
merged 4 commits into from
Apr 18, 2017

Conversation

jagerman
Copy link
Member

This applies several changes to the non-docker (and the C++17 clang docker) travis-ci builds:

  • Make all non-docker linux builds use trusty rather than precise. pybind can't actually build in precise anyway (we install essentially the entire toolchain backported from trusty on every build), and so this saves needing to install all the backported packages during the build setup.
  • Updated the 3.5 build to 3.6 (via deadsnakes, which didn't backport 3.6 to ubuntu releases earlier than trusty).
  • As a result of the switch to trusty, the BAREBONES build now picks up the (default-installed) python 3.5 installation.
  • pip is now invoked everywhere via $PY_CMD -m pip (where PY_CMD is the python binary name) rather than the pip executable, which saves us having to figure out what the pip executable is (e.g. pip vs pip3), and ensures that we are always using the correct pip.
  • Add the local user python package archive to the travis-ci cache (rather than the pip cache). This saves needing to install packages during installation (unless there are updates, in which case the package and the cache are updated), and saves a huge amount of time for the pypy and clang 4.0 builds (see below).
  • Install packages with pip --user rather than in a virtualenv. This makes the caching a bit easier: we can just cache ~/.local/{lib,bin}. (We could alternatively cache a virtualenv directory, but caching things under .local/ make it easier to also cache the local libc++ install, below).
  • Install numpy and scipy on the pypy build. This has to build from source (which adds about 8 minutes to the job time), but due to the above caching, this only happens once per numpy/scipy release. I think this testing is quite valuable: numpy has various behaviour differences under pypy (I'm anticipating that this is going to break array: implement array resize #795, which will need to skip some tests on pypy).
  • Enable numpy tests for pypy exposed a segfault in the stl_binder test: it was previously skipped because it was marked as requiring numpy, but I'm fairly sure this is the same issue as on the other test here, which didn't require numpy and had an explicit pypy skip.
  • Added set -e/+e around the before_install/install blocks so that a failure here (e.g. a pip install failure or dependency download failure) triggers a build failure. Previously such failures during dependency installation were just silently ignored.
  • Update eigen version to latest (3.3.3), mainly to be consistent with the appveyor build.
  • Switch the c++17 clang build from docker to trusty (for which clang builds are available from LLVM); the container setup is faster than docker to begin with, but it also makes caching the local libc++ installation possible, which saves a good chunk of time on every build.
  • Various small cleanups; the most notable is getting rid of the all exports on script variables (e.g. PY, GCC) which are just local script variables that don't need to be exported. The remaining exports are only for things like CXX which we do need to be exported to cmake.

@jagerman
Copy link
Member Author

And another spurious appveyor failure. :(

@wjakob
Copy link
Member

wjakob commented Apr 17, 2017

This looks great! (+1 for testing NumPy with PyPy). I restarted the AppVeyor build.

@dean0x7d
Copy link
Member

dean0x7d commented Apr 18, 2017

Awesome overhaul!

Just one small issue: pybind11's minimum supported CMake version 2.8.12 is no longer being tested anywhere. I guess this can be easily fixed by reverting BAREBONES to precise.

.travis.yml Outdated
$PY_CMD -m pip install --user --upgrade --quiet numpy pytest
echo -e "done.\nInstalling scipy..."
$PY_CMD -m pip install --user --upgrade --quiet scipy
echo "done."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are pytest/numpy/scipy installed in two stages?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a failure at one point when installing both at the same time, which looked like pip had tried to build scipy without numpy being installed yet. It didn't actually complete fail: it seemed as though pip then installed numpy, and ran the scipy build again in the same command.

I can't reproduce this locally now, however, so I'll go ahead and recombine them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... it also apparently prevented a travis no-output-for-10-minute failure, but I've added a travis-specific fix for that.

@jagerman jagerman force-pushed the travis-updates branch 2 times, most recently from d621d54 to d9e8e50 Compare April 18, 2017 15:22
@jagerman
Copy link
Member Author

Good point about cmake: I hadn't intended that. Trusty itself has cmake 2.8.12, but the travis trusty environment has a ppa-upgraded version. I've updated the first two builds to downgrade to the system version during initialization.

This applies several changes to the non-docker travis-ci builds:

- Make all builds use trusty rather than precise.  pybind can't really
  build in precise anyway (we install essentially the entire toolchain
  backported from trusty on every build), and so this saves needing to
  install all the backported packages during the build setup.
- Updated the 3.5 build to 3.6 (via deadsnakes, which didn't backport
  3.6 to ubuntu releases earlier than trusty).
- As a result of the switch to trusty, the BAREBONES build now picks up
  the (default installed) python 3.5 installation.
- Invoke pip everywhere via $PYTHON -m pip rather than the pip
  executable, which saves us having to figure out what the pip
  executable is, and ensures that we are using the correct pip.
- Install packages with `pip --user` rather than in a virtualenv.
- Add the local user python package archive to the travis-ci cache
  (rather than the pip cache).  This saves needing to install packages
  during installation (unless there are updates, in which case the
  package and the cache are updated).
- Install numpy and scipy on the pypy build.  This has to build from
  source (and so blas and fortran need to be installed on the build),
  but given the above caching, the build will only be slow for the first
  build after a new numpy/scipy release.  This testing is valuable:
  numpy has various behaviour differences under pypy.
- Added set -e/+e around the before_install/install blocks so that a
  failure here (e.g. a pip install failure or dependency download
  failure) triggers a build failure.
- Update eigen version to latest (3.3.3), mainly to be consistent with
  the appveyor build.
- The travis trusty environment has an upgraded cmake, so this
  downgrades cmake (to the stock trusty version) on the first couple
  jobs so that we're still including some cmake 2.8.12 testing.
This uses the trusty container rather than docker for the clang 4.0
build.  It also caches the local libc++ installation so that it doesn't
need to be compiled every time, which should speed up the job
considerably.
Various bash variables that are only used in the travis-ci script and
don't need to propagate (e.g. to cmake) are being pointlessly exported;
this removes these `export`s.
Adding numpy to the pypy test exposed a segfault caused by the buffer
tests in test_stl_binders.py: the first such test was explicitly skipped
on pypy, but the second (test_vector_buffer_numpy) which also seems to
cause an occasional segfault was just marked as requiring numpy.

Explicitly skip it on pypy as well (until a workaround, fix, or pypy fix
are found).
@jagerman jagerman merged commit 90bac96 into pybind:master Apr 18, 2017
@dean0x7d dean0x7d modified the milestone: v2.2 Aug 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants