miniconda doesn't seem to be available on arm, not sure about pip either, so we first need to figure out one working way to build.

E.g. I definitely suggest to try to have a build without optional dependencies, as not sure how much of them are actually available as wheels, and we definitely don't want to build them from source. Also, while you're experimenting, I suggest to add the single arm job as Initial test and remove the rest of the initial stages, so not much unrelated CI time is wasted for experimenting.

Yeah, sadly this seems to be a no go atm: https://travis-ci.org/astropy/astropy/jobs/599931761#L1193 and we're very close already to timeout without even touching astropy.

One last try if you want to list the absoulte necessary dependencies, e.g. don't use [test], but manually add numpy and pytest-astropy

Yeah, sadly this seems to be a no go atm: https://travis-ci.org/astropy/astropy/jobs/599931761#L1193 and we're very close already to timeout.

hah. We can do this old-school - apt has many of these dependencies, no need to compile if they're "system" packages.

Astonishingly, it seems to work. The general non-availability of wheels and other quick-to-install software limits the testing we can do without encroaching on the timeout. But when it comes to testing precision issues and binary portability, this is a substantially different platform we could reasonably want to support.

I'm sorry to say so, but I'm 👎 on merging this, simply because the arm run takes 37mins, even when only installing the bare minimum, and that is 4-5 times what our other travis jobs take.
Maybe over time wheels become available, and/or maybe travis would support languages on arm other than C, so things can be quicken up.

The question really is: what platforms does astropy support? And specifically, as we work on extended precision, for example in #9368 and #9361 , does our code work when longdouble is binary128 rather than binary80?

I agree the build process is agonizing as it stands. Others might build wheels, or Travis might get their cache working - both ccache to accelerate compilation, and the pip cache to store built wheels would dramatically accelerate the build process.

I don't think, as it stands, that we should add this to the mainline build process. But I think it would be good to keep it around so that it can easily be merged when the build process does become more reasonable, and also so we can temporarily turn on arm64 builds in branches where we are worried about whether astropy behaves properly.

@aarchiba - see the slack thread on this. We're thinking about having this turned included in the release branches, but not on master until the build time issues get sorted out, one way or the other.

@aarchiba - see the slack thread on this. We're thinking about having this turned included in the release branches, but not on master until the build time issues get sorted out, one way or the other.

uh, which slack thread? I don't see anything relevant on any of the threads I know of... that sounds like a perfectly reasonable option (though I note that they now have cache and I'm poking around to see whether that helps and how much).

I will say that I don't feel any special urgency about this, it's not something I'm trying to get in before the feature freeze, I'm just curious and when at some point I start trying to hammer Time with hypothesis I'll want to know what happens here too.

testing related stuff are not bound to feature freeze anyway, they can come at any time ;)

Uh, weird. The built wheel is not working out of the cache - it may be the case that the cache does not distinguish hardware architecture? Or wheels just can't cope with non-x86 hardware?

Since this could have prevented the problems now happening because Debian does support arm, is there any way to cut the time needed? Above, I read about installing via apt vs pip - apt might well be faster as everything is precompiled. It would also mean we automatically test whether people who are on Debian-derived distributions will be able to install astropy (since that includes me, it would make me happy!). If it is simply too long for regular testing, a cron job might still be an idea?

In principle, I think careful planning could get this working without heroic effort. On my arm64 SBC I installed essentially everything from pip, and what took forever was building all the wheels for all the compiled code. Once built, pip installing everything was fairly quick. In principle the Travis cache is capable of keeping all those wheels, but it's a bit flaky in general and on arm64.

What packages are available from apt I don't know, but indeed that would help a lot.

In fact I believe there were headaches when using apt because the apt installed versions of (say) numpy were not being used because pip felt the need to replace them with pip-compiled versions.

Since Debian ships astropy, it must logically be possible to get all the dependencies via apt and avoid pip altogether... but we'll soon find out: I'm trying an apt-only version in #9663 (for the s390 architecture, but that will be easy to switch/enhance if I get that to pass.

superseded by #9668