@maartenbreddels - is there any possibility of trying to contribute these fixes upstream to the six developers instead? It would be best to avoid having to deal with a patched version of six in astropy if possible, so I'm just curious whether this can't be fixed once and for all in six.

Sorry for the confusion, I mean the https://github.com/vispy/vispy/blob/master/vispy/ext/six.py module, which is simular to astropy.extern.six (and not astropy.extern.bundled.six).
So it's the module that does the loading of the six module or the bundled six module.

I guess the build fail has nothing to do with this PR right?

@maartenbreddels - ah yes of course, please ignore my comment :)

Indeed the build failure is unrelated, and fixed in a separate PR that still needs to be merged

I have to say that running frozen_astropy test (which runs the unitstests in the frozen env) doesn't pass all tests, but they don't seem crucial. And I've been able to use it within vaex successfully. But at least this enabled importing astropy, which is the first step.

@maartenbreddels - note that @embray did some work related to this in the past that might contain some fixes that should still be included: #960

Ah yes, I knew that PR/issue existed, but thought it was 'dead' and required quite some changes/rebasing. I used that fork in vaex before, but needed newer features. Instead of going the .egg route, I work with the source version. But I think that if #960 goes into the master as well it may resolve some of the failing unittests. And, nice work @embray!

This looks like overkill to me. Over in setuptools Jason Coombs tried to adapt my version of astropy/extern/six.py for the same purpose, but ran into the same problem. Instead he came up with this much more elegant PEP 302 loader as a solution, and I've been meaning to adapt it

https://bitbucket.org/pypa/setuptools/commits/7c902993cb62

What do you mean, 'same problems'? This seems to work for vispy, and also works for astropy (when source is available, not using an egg file).

What do you mean, 'same problems'?

The same problems that my current solution has with working from a zip import. The import-hook based technique added recently to setuptools doesn't appear to have any problem with this and is much simpler.

Regarding #960, I rebased it a few weeks ago and got astropy fully working from a zip import. However, it looks like I need to rebase it again (probably due to all the recent changes to remove Python 2.6-specific code).

Does you solution work with only an egg file or should it work with a 'normal' install?

I don't know what "solution" you're referring to exactly.

Doc build failure unrelated to #4547

six will be removed in v3.0 along with Python 2 support. So I don't think we need to merge this because then we have to undo it anyway?

Thanks @maartenbreddels for working on this.
However, I'm closing this now as we're about to remove six.py and all python2 support from astropy master, so this PR won't be relevant any more the new release.

np 👍