try xenial and python 3.8

[charris]

No description provided.

[mattip]

Does multibuild support 3.8 ? I don't understand how the new virtualenv is supposed to be activated because in both the unsucessful job here and in the successful 3.7 job it seems a 3.5 virtualenv is activated?

@matthew-brett any ideas?

[matthew-brett]

The way it works for Linux is: * Multibuild starts any old virtualenv on the Travis-CI container - in this case, a Python 3.5 virtualenv * From there, it spins up a Manylinux container, activating the appropriate Python version there, and builds the wheel * When that returns, Multibuild spins up a test container, activating the appropriate Python version, and tests the wheel. For Python 3.8 support we need: * Python 3.8 on the Manylinux container * Python 3.8 on the test container. I maintain the test container, which is now very old: https://hub.docker.com/r/matthewbrett/trusty

[mattip]

Reading through the PRs for 3.8 in manylinux it seems the merged 3.8a2, then backed it out since the ABI is not stable until release. So we can only build/test wheels after it is officially released? That seems strange.

[mattip]

Ahh, my bad. pypa/manylinux#333 has a stable ABI, but something else is preventing merging it into manylinux, something about keys

[mattip]

https://hub.docker.com/r/matthewbrett/trusty

Would you accept a PR to https://github.com/matthew-brett/trusty for any or all of the following?

• upgrade trusty to xenial 16.04 since trusty is EOL
• use 3.8b3
• use python -mensurepip; python -mpip install --upgrade pip setuptools instead of get_pip.py

[matthew-brett]

Yes, absolutely - I'd love help for the test images. Maybe we could make a Numpy dockerhub account or similar, and host there. I don't think it would make sense to reuse the Trusty repo - maybe something like a multibuild-test repo, and start with a Xenial container there? I think the Dockerfiles would port OK, although the 32-bit version might be annoying - it was for Trusty.

[mattip]

a multibuild-test repo

Open the repo, and give me permissions. I'll see what I can do

[charris]

How about bionic instead of xenial?

[mattip]

@charris what do you think of this claim: most the developers will be testing with a more modern system, it would be good to make sure we are not leaving xenial users behind.

[matthew-brett]

What do you think about hosting the repo in the numpy organization?

[mattip]

multibuild as well? They go together, no? Can you join the zoom meeting today, at least for part of it, to discuss this?

[matthew-brett]

Yes, sure - I'll join the meeting at the beginning if I may (dogs allowing).

[charris]

it would be good to make sure we are not leaving xenial users behind.

We are talking about generating wheels on travis and mostly the testing environment, I think. The only problem I can see with bionic on travis is that python2.5 is no longer supported, on the plus side, that is another two years we can leave off fiddling with it. In any case, once we figure out how to change the distro it should be easy to do it again :)

[mattip]

This will have absolutely no effect and probably should just be removed so travis uses its default. The containers used in the build and test phases are different from this one. The actual image used is controlled by the build_wheel and install_run function calls in this file, which set the docker image to use from multibuild/travis_linux_steps.sh