Data files installed without read permission with Astropy 1.3.1

@lpsinger filed this issue in the Macports tracker: https://trac.macports.org/ticket/53865

Since Astropy 1.3.1 the “data files” from Astropy are installed in Macports without file permission that prevent them being read by non-root users and thus import astropy fails because astropy.cfg in site-packages can’t be read.

This is a bit surprising since I think the issue was introduced with the Astropy 1.3.0 -> 1.3.1 update, with no changes on the Macports side: https://github.com/macports/macports-ports/commit/5c14ebc3d35e816cebb24ce08f85b1deec473eb6#diff-9bf981826bafa297ea70fa2ff3e20a21

We had noticed a while back a similar file permission issue for photutils in Macports, but didn’t manage to track down the cause (and there it only affected running the tests, not photutils itself): https://github.com/macports/macports-ports/pull/214 If someone knows the Astropy build system well, looking at this full log (for the photutils build) might reveal the issue: https://gist.github.com/cdeil/88f8e48d85d1c65f593d81db1e7e0d92#file-gistfile1-txt-L1151

@astrofrog @bsipocz - Has there been any change on the Astropy side, e.g. in astropy-helpers, that could lead to installing files without the “read” premission flag set?

@lpsinger @hamogu as Macports users – any idea what the cause or fix here could be?

I’m pretty clueless how to debug or fix this issue. So unless someone here comes with a suggestion within the next day or two, I’ll roll back the update to the previous 1.3.0 in Macports.

[astrofrog]

Ah ok hmm, well then maybe 1.3.2 makes sense then.

[lpsinger]

It also says:

Creating post-releases of pre-releases is strongly discouraged, as it makes the version identifier difficult to parse for human readers. In general, it is substantially clearer to simply create a new pre-release by incrementing the numeric component.