Add support for helm bindings in OSX

[uberspot]

As a followup from #359
This ticket is to track the work for OSX helm bindings + testing them on Travis.

cc @yoshi-1224

[yoshi-1224]

@uberspot Thanks for creating this issue!

As of now I only have few suggestions:

Using travis

Travis does have OSX platform available like you have pointed out and we can run tests in multiple platforms, but what we want to do is to collect the built artifact (i.e. the binding) from osx and pass it to the build on xenial such that we can deploy the source including both bindings to PyPI from xenial (or one of the builds) right? Not sure if this is possible, so directly uploading to PyPI from Travis may not be the option (i.e. we likely need something in-between where we can combine the artifacts and then release to PyPI), unless we can immediately add the macos binding to the existing PyPI release (is this possible?).

What we can try is to release the macOS binding on Github and add some code to helm input so that when running on Mac we can dynamically fetch the file into the kapitan directory from URL (e.g. https://github.com/deepmind/kapitan/archive/v0.24.0/macos_helm_binding.so). I see here travis-ci/travis-ci#6224 (comment) that it is possible to deploy from multiple builds to Github releases (worst case we can manually add it since the so file won't change).

cross compiling

I realised that the issue with cross compiling on Linux is the license agreement for Mac SDK which states it can only run on Mac devices. So if we abide by that, I believe this option should be avoided: most of the popular tools like osxcross are not probably created in consideration of this license.

[ademariag]

This would be very cool to have.... Any updates?

[yoshi-1224]

@uberspot Happy to help

[uberspot]

Go for it :) happy to review any PRs when you have em.

[yoshi-1224]

@uberspot
So any suggestions as to what we should go with?

[uberspot]

Yes, sorry I had to think a bit on the possible solutions.
Dynamically fetching the .so file when kapitan runs might be a bit "dodgy" security-wise. It's very rare that templating tools download shared libraries dynamically from the internet. And that might be also hard to do in environments that have restricted access to the internet.

I'd like to try and keep the steps of building the .so library in travis (osx) independent from the packaging steps to simplify maintenance.

So I'd suggest as a first step on this, let's focus on creating a travis job/pipeline that would build the osx bindings on travis (osx) and just release them to Github Releases. This should only happen on the master branch, same way we currently release to pypi and GH.

A second step after that would be actually packaging the bindings to our pypi release.
That could either be a manual step a maintainer does (less preferred) or if possible we could modify the existing travis job to wait (on the master branch) until the bindings are available (https://docs.travis-ci.com/user/common-build-problems/#my-builds-are-timing-out travis_wait referenced here).

That is a less elegant solution so I'd leave that as a further step and focus on first building and releasing the bindings on travis. :)