Hi @bsipocz, I have opened this PR to replace the old one (#8377) so as to allow me to polish up the documentation on the development workflow instead of just focusing on removing the notes about the version incompatibility issue. The scope of the previous PR was too narrow, besides the problem dealt with therein had already resolved by some one else in PR's #7287 and #8289. I will need to go through the documentation at least once in its entirety while I learn about the workflow for the first time myself. This would be great preparation for me to participate in this year's GSoC (2019). My old development version installed on my machine was a 2.x development version, so it was quite outdated. I had installed it in the hope of someday contributing to the astropy community, which is becoming a reality now. Thanks so much for your patience, time, and effort in guiding me through the process. I have learned so much from you in this short span of time already, and I appreciate it.

Codecov Report

Merging #8385 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8385   +/-   ##
=======================================
  Coverage   86.77%   86.77%           
=======================================
  Files         387      387           
  Lines       58134    58134           
  Branches     1060     1060           
=======================================
  Hits        50446    50446           
  Misses       7073     7073           
  Partials      615      615

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 43eb759...0ccad04. Read the comment docs.

Hi @bsipocz and @mhvk, I have fixed the bug in the code by removing backticks in L261, and now the commits pass the checks. Please advice how I should proceed next. I would appreciate it.

I think I will need to check on the consistency of the other parts of the "development workflow" documentation as well, especially the parts regarding installation, as someone else has reported some discrepancies. I will look into this further before I commit any more changes.

Hi @bsipocz and @mhvk, I have fixed the bug in the code by removing backticks in L261, and now the commits pass the checks.

single backticks are tried to be rendered to intersphinx links. For highlighting you can use double backticks (as opposed to quotation marks that indicate that something is supposed to be a string)

@bsipocz Yup, thanks! I now recognize my previous mistake.

And, after some trial-and-error, I can report that python3 setup.py install works whereas python3 setup.py develop doesn't at this stage.

I also managed to find this section with some outdated installation notes from the development workflow "git-edit-workflow example" page: http://docs.astropy.org/en/stable/development/workflow/git_edit_workflow_examples.html#set-up-an-isolated-workspace

In here they recommend the method for Python 2.x that wouldn't normally work for Python 3.x, as I have tested things out myself. But astropy-helpers requires Python 3.x, as when I tried to install using Python2 I got the error message:

$ python2 setup.py develop
ERROR: Python (3, 5) or later is required by astropy-helpers

So I think it is safe to phase out the implicit reference to Python 2.x.

Next, I will test out whether the installation command python3 setup.py develop works. By python3 I mean the executable that can be found at location like /anaconda3/envs/py37-stable/bin/python3.

Indeed, astropy >=3.0 supports only python3 and it would be great to remove all references to python2...

Agreed. And I noticed that pip install -e . effectively replaces python2 setup.py develop, as I see the following line while running the former:

Running setup.py develop for astropy

Just changed the part of the deactivation section where once again the deprecated develop method is invoked with a -u flag... Originally the command python install develop -u is used, which essentially is an implicit reference to Python 2.x. So now this line has been changed to pip uninstall astropy within the AstroPy development version directory.

Yup, using the command python3 setup.py develop to install the latest development version appears to work. But I would rather use pip install -e . as the default and the former as a backup... (All tests passed with 0 fails and 0 errors.)

Also, I noticed that the executables /anaconda3/envs/py37-stable/bin/python3 and /anaconda3/envs/py37-stable/bin/python might yield different versions, so I prefer using python3 on my machine.

Think the commits are ready for a review.

Thanks @mhvk for the review... am working on implementing the changes.

Yup, all looks well especially with the checks... Ready for a final review?

Think the commit(s) is now ready for another review... All tests/checks passed after rebasing and squashing.

I can add any other details as footnotes if desired.

Hi @bsipocz, would it be possible for me to get a review from you as well? I would appreciate it very much.

As a suggestion, I think I can loop the "Try the development version" back to the "How to make a code contribution" page, to add some (potentially convenient) closure as it is natural for the user to want to get back to the latter after having gone through the former to install a working development version.

Thanks @kakirastern!

You are welcome @bsipocz