This seems over complicated for its stated purpose.

There are four changes:

1. change the test matrix to define the python and pip explicitly
2. percolate those choices into the chroot
3. install into the chroot python3 packages that were missing
4. replace pip with $PIP

If we wish to only support python3 it can be simplified by removing 1, hardcoding python3 and pip3 into 2, and dropping the python2 packages from 3.

I think 4 works outside the chroot because it is using a virtualenv, not clear to me if inside the chroot it is also in a virtualenv.

I wonder if we can run 32 bit linux tests on azure-pipeline? We still have some slots before we hit the 10 parallel build limit. That doesn't help for releases yet, as they are still built on appveyor and travis, but it tmight be an easy way to get 32 testing on linux.

As it is running in bionic, the default python3 is 3.6, which should be good for a while. Did you try just changing things to *3 in the chroot? And then in the calling lines

  sudo linux32 chroot $DIR bash -c \
    "cd numpy && PYTHON=python PIP=pip IN_CHROOT=1 $0 test"

use python3 and pip3?

32 bit linux tests on azure-pipeline

Pretty sure numba does this--I'll try to take a look today. There's also a recent Azure Pipelines blog post that seems to announce availability of Raspberry Pi arch testing and various 32 bit archs.

Also, might be worth simplifying the i386 tests as suggested in the note

  # this can all be replaced with:
  # apt-get install libpython2.7-dev:i386
  # CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" \
  #   linux32 python setup.py build
  # when travis updates to ubuntu 14.04

EDIT: travis was to have switched to 14.04 as default in Aug, 2017.

Did you try just changing things to *3 in the chroot?

@charris Then we can only run chroot python3 tests. Is that OK, or do we wish to preserve the possibility of running python2 by changing .travis.yml only?

this can all be replaced with ...

There are two parts to the travis_test.sh file: building and testing. That section may build a 32-bit numpy, if it links correctly with OpenBlas, but then we will need further changes to run the 32 bit python for testing.

This seems over complicated for its stated purpose.

Do you mean my changes or the whole chroot 32 bit testing option in travis-test.sh?

Travis itself suggests using docker, here is one example of a 32 bit docker command, it does not look less complicated than what we now have.

I could try pursuing the linux32 option if so desired

or do we wish to preserve the possibility of running python2.

We will be dropping Python2 support in a couple of weeks.

changed to only use python3 in chroot

Thanks Matti.

The 32-bit 3.x Azure linux build seems prone to stalling during unit tests, so that's where I'm stuck at the moment on that.

I wonder if i.e., 32-bit build / test on a 64-bit OS without linalg acceleration libraries is prone to issues -- I think that's my current config there. My first pass at getting the :i386 linear algebra stuff working was a bit of a mess, but the library otherwise builds and runs the first 30 % of the unit tests in full mode before stalling.

Interesting. Does it always stall at the same test?

I think so, and same stall for 2.7 & 3.5. libpython3.6-dev:i386 doesn't exist on the Azure Ubuntu version, but I think I can perhaps try libc6-dev-i386 + 3.6-7 now that I'm mimicking the numba approach with 32-bit conda env + gcc_linux-32 gxx_linux-32