@WasabiFan I am able to verify that this fixes clean_arena() for micropython

Nice find! Ideally we'd just bump the version of Micropython we install on Travis, but given that ev3dev images come with v1.9.4 I figure we should probably keep that. Any idea why this changed suddenly?

I'm not sure what it is about the Buttons pull request that exposes this (didn't dig that far once I found the os.walk bug). Agreed on sticking with v1.9.4 since that is what is shipping on ev3dev.

It wasn't the buttons that broke it; it was time. I'd still ideally like to know what it was that changed, because the version of Micropython that we are testing with hasn't changed. So something else caused the failures.

time?

The same build that passed a week ago failed when we re-ran it. Something in our dependency tree changed between then and now to cause it to stop working.

This is a head scratcher

• .travis/install-micropython.sh had not changed since September 2018
• micropython v1.9.4 had not changed since May 2018
• ev3dev-lang-fake-sys had not changed since September 2018

If I use a version of ev3dev-lang-fake-sys without our recent shutil.rmtree patch I am unable to find any commit in ev3dev-lang-python where I can get ~/micropython/ports/unix/micropython tests/api_tests.py to pass (I deleted micropython, ~/.micropython/, and installed per our travis install-micropython.sh). I went all the way back to when we first added micropython support in Sept 2018.

Maybe we were somehow hitting this part of install-micropython.sh and were using a cached version of micropython that did not have the os.walk bug that causes shutil.rmtree to fail?

if [ -e ~/micropython/ports/unix/micropython ]; then
    # the micropython binary already exists, which means that the cached folder was restored
    exit 0
fi

I don't know enough about travis to know if that is possible but that is the only reasonable theory I can come up with so far.