Try re-enabling OSX (Python 3.x)

[patricksnape]

Since Travis now has two cores this might work again (since Ninja automatically builds in parallel)

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[Korijn]

Would you mind also opening a PR for the second master branch for py27?

[jakirkham]

Also needs a re-render to get the .travis.yml file back and thus start the Travis CI build.

[patricksnape]

It's weird, it's like it's even slower with two cores - older builds used to get to the copying phase before running out of time. Although, this does contain the newer OpenGL2 stuff so maybe that is much slower to build?

[Korijn]

I sure would like to see this thing pass for once... I doubt we can make the build even faster without more trial-and-error fun with cmake parameters... perhaps some Kitware devs could give us advice? Maybe there are some less important groups of VTK modules that we can disable to shave off some build time?

[jakirkham]

Went ahead and started a fresh attempt in PR ( #42 ).

Edit: Did this as we have combined Python 2 and Python 3 together in one branch again (and wanted a fresh PR to start 😜). Hope that is ok.

[jakirkham]

I sure would like to see this thing pass for once... I doubt we can make the build even faster without more trial-and-error fun with cmake parameters...

...or some amazing improvements to ninja. 😄

...perhaps some Kitware devs could give us advice?

Not totally sure who to ask. Maybe @jcfr knows some build tricks. 😉

Maybe there are some less important groups of VTK modules that we can disable to shave off some build time?

That also sounds like a good idea. Though I'm not totally sure what to take out ATM. Seems like you guys have already picked the right things at a basic level. Would have to comb through the docs.

---

We can probably also shave a minute or so if we cache some stuff like the Miniconda installer, possibly conda packages, etc. Though I don't know how much it will help as that stuff ends up on S3 whether Travis CI caches it or if Continuum provides it. This would be a bit exploratory. Though some work has been done on this front.

[jcfr]

knows some build tricks.

Look like you are already disabling testing and examples. You could try to disable MPI related modules.

[jcfr]

Also, effort to support building VTK wheels are happening here: https://github.com/jcfr/VTKPythonPackage

We should be able to repackage the vtk wheels into conda packages.

Similarly to what was done for ITK. See [1][2][3]

[1] https://github.com/InsightSoftwareConsortium/ITKPythonPackage
[2] https://blog.kitware.com/itk-is-on-pypi-pip-install-itk-is-here/
[3] https://github.com/conda-forge/itk-feedstock/blob/master/recipe/build.sh

cc: @thewtex

[Korijn]

Repackaging wheels is definitely something we can look into. We're also considering that approach for https://github.com/conda-forge/wxpython-feedstock

Is the wheel repackaging effort sustainable? E.g. what are the odds of the maintainers stopping their efforts in the future?