Travis-CI: Fix Container Network

[ax3l]

Add --network=host to Travis-CI PPC64le runners.

Draft to fix #904

Test in openPMD/openPMD-api#1138

[henryiii]

I don't think this should be added for everyone due to travis issues. I also think we need to think about how to provide a little more flexibility for the docker command (say to support podman). Maybe we could add a configuration option for controlling the command, and then you could use overrides to add it just for ppc64le?

Also, Travis's ppc64le is really a mess last I checked. Manylinux can't build using it still (maybe this is related).

[ax3l]

Sounds good to me, how would you propose the control for the config option?

As an alternative, I tried again building a my project with emulation on GH actions to avoid travis, and its so slow, that I cannot get a single ppc64le build out in 360min ^^

[henryiii]

I'd think some sort of option / set of options. I think it should be flexible enough to allow this and #691 too, if possible.

[joerick]

What about wrapping this in a detect_ci_provider() == CIProvider.travis_ci? I think I'd prefer that to exposing another option on our API.

[henryiii]

I was thinking we need this anyway, #691 was about adding support for other runners (podman). If we allowed configuration here, we could also use this to allow users to work around broken Travis runners, solving both issues with one change.

The problem is Travis's, and I don't know if it's temporary or permanent (it's Travis, so it might be permanent if it it should be temporary). I like that detecting it would automatically fix it (but we should probably limit it to just the broken PPC arch, maybe just the Sao Paulo workers, as I think it's only that cluster that's broken).

[henryiii]

Actually #340 is a better reference. The idea is that podman (and singularity, if it's close enough) are image runners that don't require sudo access. At least podman is close enough to docker that just configuring the command slightly would enable it to be used. And if we have a way to configure that generally, then we could use that to allow someone to add this flag as a workaround for Travis's issue.

[joerick]

My feeling (based on a podman fork I saw) is that a change to a different container system would require more than just changing the invocation command of the runner, it would be more like CIBW_BUILD_BACKEND - choosing between a set of container systems (E.g. CIBW_CONTAINER_RUNNER, choices docker, podman etc) - not choosing the exact command to be run. I suppose that the above could be integrated into such an option (docker-network-host), but with this being just a temporary work around, it's probably better just to get it in and worry about the API stuff later.

[ax3l]

Re-starting CI

[henryiii]

Shouldn't we check for Travis CI, and only apply the fix for that CI system?

[joerick]

Looks good to me! I think the CircleCI build failure is unrelated.

[mayeut]

LGTM, thanks @ax3l

[mayeut]

The failures are all unrelated so merging this.
Let's see if they also appear on main...

[mayeut]

failures probably related to pypa/setuptools#3002