@mhvk - Can you add the switch over python3.5 to this issue? It makes little sense to me to open a separate PR and repeating everything from this issue. (and I can't turn this issue to a PR since you opened it). I think none of the action items above applies to this PR except the change in the travis file.

So I guess the next thing we can do is first make sure that we can get RTD to work correctly with a Python 3 build?

Yes I think so. Then backport the relevant PRs to a 1.0.x helpers release.
I can try and test it locally/on travis, but can't do the backporting properly or the release.

@bsipocz - OK, I made this into a PR that changes the travis sphinx build to default python, i.e., 3.5. (Just so the flow remains clear, I also added a "done" item to the above checklist.)

Sphinx build passing here, so maybe time for the next step? It would seem that all one has to do is to switch to CPython 3.x in the advanced settings on readthedocs...

@mhvk - changed, and the docs are now being built. Standing by...

@astrofrog - did the RTD python3 build work? If so, I guess this one should be merged so travis and RTD do the same thing, and we should open a new issue with the remaining items from the checklist...

@mhvk - I think it did. Check the latest docs and try and find a link to the Python docs (e.g. instances of True or False) and I think it should link to Python 3 docs.

And I've started to test 1.0.x locally to see what's needed to make it work.

@astrofrog - indeed, None, True, etc., now link to python3 ... but looking more closely, that seems to hold for all astropy versions because those didn't point to a specific python version anyway.

I tried to find some TypeError etc but at least those in the Raises parts of docstring do not seem to be turned into links generally.

@mhvk - Those were never turned into links or at least not consistently (I have a long abandoned PR to change them over, but it was manual and wasn't sure we want that anyway, maybe I should revive it at some point during a cleanup).

Something is not right yet, e.g. the hooverover len still shows py2.7, while the link point to py3:
http://docs.astropy.org/en/latest/modeling/index.html#model-sets

Unfortunately, the CPython 3.x switch has no effect when the builds use Anaconda (I discovered this recently but didn't make the link with this PR before, sorry).

I mean, if you look at the detail of installed packages, the -py27_0 versions are installed.

Could you link the line please?

@bsipocz - I think https://readthedocs.org/projects/astropy/builds/4168563/ should use Python 3, but click on the 'conda install ...' block to see the installed packages.

Maybe adding something like python=3.5 in the environment file could change the python version.

@astrofrog @mhvk - So to make it work on the v1.0.x branch, we need to following backports:

• Fixing links to make sphinx built pass with py3.5  #4556 that fixes the links, it's not a clean backport though as the helpers shouldn't be updated

And the helpers v1.0.8 release needs at least this:

• Python version dependent local sphinx inv astropy-helpers#216 that introduces the python version dependent intersphinx files

Cherry-picking these pass both sphinx tests: https://travis-ci.org/bsipocz/astropy/builds/142852685 (ignore the first one as there was an error in the cleared out travis file)

In addition, as the latest v1.0.7 helpers is failing due to various reasons, to have a passing version the following backports are needed (to be able to deal with the newer sphinx and setuptools versions):

• Fixing extension warnings raised by sphinx 1.4 astropy-helpers#224 fixes pngmath
• Work around sphinx 1.4 warning astropy-helpers#229 fixes autoattribute
• rename _eva_ to apyhtest_eva astropy-helpers#230 fixes eva

Cherry picking the relevant commits passes on the tests: https://travis-ci.org/bsipocz/astropy-helpers/builds/142843894

Using all the helpers backports it still works: https://travis-ci.org/bsipocz/astropy/builds/142861025

Adding:

  - python>=3

to the environment file works.

@astrofrog - I slightly lost track here: should we go ahead and add the python>=3.5 line to the RTD setup now so that those builds start to use python3? If so, we could move ahead and merge this (and open a new PR for the remaining items).

@mhvk - Can you try and add that to readthedocs.yml to see whether it works now?

@bsipocz - you mean in this PR? Do we then have to merge it to check that it works?

Oh my bad, you're right of course.

OK, I changed .rtd-environment.yml -- is that the correct one?

I think it should be a version: >=3.5 line added under python in readthedocs.yml. Though this may work as well (as .rtd-environment.yml is the one to control the conda packages for the environment).

I copied my change from #5135 (comment) - but am of course happy to change. A line in readthedocs.yml does seem more logical...

I assumed the other file based on this readthedocs/readthedocs.org#1901, but I guess both should work.

I think it will work as it is at the moment and it won't change anything to specify it in readthedocs.yml too, but I'll double check.

Here's a test build: http://astropy-test.readthedocs.io/en/latest/ - I haven't had a chance to check whether it worked, but could someone else take a look?

@astrofrog - general links (e.g. object, False, IndexError) still point to the python2 docs in your link.

Weird, the build was using Python 3:

http://readthedocs.org/projects/astropy-test/builds/4231016/

For instance you can see it loaded the Python 3 object inventory:

loading intersphinx inventory from http://docs.python.org/3/objects.inv...

and

loading intersphinx inventory from /home/docs/checkouts/readthedocs.org/user_builds/astropy-test/conda/latest/lib/python3.5/site-packages/astropy_helpers/sphinx/local/python3_local_links.inv...

I think that's a simple caching problem. If I check the Build-Messages it says Finished processing dependencies for astropy==1.2.dev15876 but the docs are Astropy v1.2.dev15874.

In my experience it seems non-deterministic which version is displayed but sometimes clearing the version and then building it again works (although this may be an iterative process).

I think it worked after wiping and restarting:

http://astropy-test.readthedocs.io/en/latest/

for instance if I click on 'None' in this page:

http://astropy-test.readthedocs.io/en/latest/api/astropy.stats.bootstrap.html#astropy.stats.bootstrap

I get redirected to the Python 3 docs.

@bsipocz - can you confirm this worked?

Yes, the things I checked randomly all look good.

I think we can go ahead and merge this now. The only impact on users will be that they will get redirected to the Python 3 docs instead of Python 2 for intersphinx links, and I think that's fine (since in 95% of cases the content is the same, just more nicely formatted).

@eteq @taldcroft @kelle - as coordinators, any objections?

I rebased, so this should be mergeable again.

Shall we merge this?

@astrofrog - thanks for merging this! However, I noticed the following issue with this pull request:

• Changelog entry not present (or pull request number missing) and neither the Affects-dev nor the no-changelog-entry-needed label are set

Would it be possible to fix this? Thanks!

This is an experimental bot being written by @astrofrog - let me know if the message above is incorrect!

@astrofrog - do you want to move the remaining items on the checklist on top to a new issue?

I don't have time this evening - would you have time to do it now? If not, i'll do it tomorrow.

@astrofrog - OK, new issue is #5246

Milestoning this as 1.3.0 since as discussed in #5246, we don't need to backport this type of change. The Python version is set by the RTD YAML environment file, which means it's possible to build different versions of Astropy on different Python versions.