add mac wheels for 10.9 / 64b only

[robbuckley]

resolves #42 for master
cherry pick from daily 978fdc2
also align build matrix with daily

• update multibuild submodule to support building osx 10.9 / 64b only wheels
• make 10.9 builds the default for osx
• move override of pandas MACOSX_DEPLOYEMENT_TARGET from .travis.yml to config.sh for osx
• remove python 2.7 builds

[robbuckley]

@jreback ping. This updates multibuild the the same version as daily, and changes the macOS python 2.7 and 3.6 builds to target macOS 10.9+.

[jreback]

so master needs to be updated to remove 2.7 support
is the daily one ok? if so then we can just make master match it

[robbuckley]

yes, i think daily is OK (modulo periodic breakages due to churn on pandas master). I removed the 2.7 builds, and reordered the build matrix similar to daily

I kept the 3.5 32b linux build, even though its not on daily as it was added fairly recently in #35 There are a few other diffs with daily, which I also havent changed: numpy min version, and versions of pytest and pytest-xdist

I'll sanity test the mac wheels locally once they've built.

[robbuckley]

@jreback the 3 macos wheels from my fork install OK for me locally.

All builds have a string of INTERNALERROR> lines, although they dont seem to affect the ability to build wheels, and they are on the head of master too. They seem to be backtraces for these 2 exceptions:

INTERNALERROR>   File "<remote exec>", line 119, in pytest_collectreport
INTERNALERROR> AttributeError: '_HookRelay' object has no attribute 'pytest_report_to_serializable'

and

INTERNALERROR>   File "/Users/travis/build/MacPython/pandas-wheels/venv/lib/python3.6/site-packages/execnet/gateway_base.py", line 707, in send
INTERNALERROR>     raise IOError("cannot send to {!r}".format(self))
INTERNALERROR> OSError: cannot send to <Channel id=1 closed>

[TomAugspurger]

The version of pytest being picked up (3.8.2) is quite old. That may be the source of the collection error.

That's being set at https://github.com/MacPython/pandas-wheels/blob/master/.travis.yml#L87.

[TomAugspurger]

I'd prefer to move this setting to pandas. We should have an extra_requires for pandas, and install pandas[test] which installs the necessary versions of pytest and hypothesis.

[TomAugspurger]

I already opened pandas-dev/pandas#25593 for that :) I'll make a PR to pandas, and we can use it here.

[robbuckley]

Sure, but that shouldn’t block this PR from being merged, should it? Let me know if I need to do anything more here

[TomAugspurger]

The tests aren't actually being run right now. https://travis-ci.org/MacPython/pandas-wheels/jobs/549413737#L4004

I'll make another PR updating the pytest install and then we can re-run this on top.

[robbuckley]

Now you mention that, I do remember thinking the wheels were building quite a bit quicker than I remembered...-:)

[robbuckley]

@TomAugspurger I can get most of the tests running on master by allowing pytest to use the latest (removing the pin to 3.8.2) plus #49 which is already on master. There are still a couple of issues with this:

• in all builds it looks like all markers are being flagged with PytestUnknownMarkWarning. This is new in pytest 4.5.0. My trials builds pulled 4.6.4. Not sure if this is an issue
• 1 collection error in each of the 2.7 linux builds, although these dont trigger a travis fail:

2.7 linux 64b

_________________ ERROR collecting tests/resample/test_base.py _________________
In test_resample_interpolate_all_ts: function uses no argument '_index_factory'

2.7 linux 32b

_________________ ERROR collecting tests/resample/test_base.py _________________
In test_resample_loffset_arg_type_all_ts: function uses no argument '_series_name'

[TomAugspurger]

Sorry for the delay. Looking now. We don't need to worry about 2.7 anymore.

[TomAugspurger]

Whoops, I didn't realize this was also syncing master with daily. I did that over in #53

@robbuckley can you confirm that things look OK on master now? We have

• https://github.com/MacPython/pandas-wheels/blob/master/.travis.yml#L8
• https://github.com/MacPython/pandas-wheels/blob/master/.travis.yml#L49
• https://github.com/MacPython/pandas-wheels/blob/master/config.sh#L7

[robbuckley]

@TomAugspurger no problem. The multibuild submodule version needs to be updated to match the one on daily. Then the macOS py36 and py37 wheels will be generated for macOS 10.9+ 64b rather than 10.6+ 64/32b. Moving to 10.9+ wheels should avoid possible problems along the lines of pandas-dev/pandas#23424. That was the original intent of this PR.

Also, you have removed the linux py35 32b build, is that intentional? It was added to master fairly recemtly, in #35

Everything else looks good.

[robbuckley]

I built wheels off the current master, and confirmed the mac ones are wrong (they are all 10.6+ dual arch). I've rebased and pushed the multibuild change to this PR. The mac wheels build OK on my fork: the 3.6 and 3.7 wheels are 10.9+ 64b.

[robbuckley]

ping @TomAugspurger @jreback, any chance of getting this merged?

[TomAugspurger]

Thanks. I'll followup on your comment in #48 (comment)