Conversation
… main coordinates
…oords-format Fix bug that caused format for display coords to always be taken from main coordinates
…tation Keep representation
Generalize handling of x/y index
Try and re-enable Numpy 1.5 and Matplotlib 1.2
…ations-as-exceptions Enable deprecations as exceptions
…te-0.4.1 Updated package template to v0.4.1 (includes update of astropy-helpers to v0.4.3)
Fix typo in TestBasic.test_rcparams that caused a fail
…or WCSAxes, as the listed copyright holder, I am fine with removing the license, and the license itself is word for word the Astropy one.
2725041 to
bea41dd
Compare
|
Made one final set of small changes, but this looks good now! Assuming the tests pass I'll go ahead and merge. |
|
All done, and looks good. Thanks for all the work on this, @astrofrog ! |
|
@eteq - thanks for merging this! However, I noticed the following issue with this pull request:
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! |
|
Oopsie, forgot the changelog entry 👼 |
|
Added changelog entry in f5d097f |
|
This is very exciting! 🎆 |
|
One would step away from the computer for a few hours to chat with friends on a Friday evening, and coming back a fetch brings in this: |
|
@eteq - presumably this also needs a what's new |
Background
The WCSAxes package was developed with the intent that it would some day be merged into the core Astropy package. Since it is now stable, a number of people have asked for it to be merged. It would be nice to include this in the 1.3 release!
Update: this is now ready for review! You can view the rendered documentation here:
http://astropy-test.readthedocs.io/en/latest/visualization/wcsaxes/index.html
Once #5506 is merged, we can update the WCSAxes tests so that they get run in
--remote-data=astropymode.Open questions
Any objections to include WCSAxes in Astropy?
Any objections to including the full git history? (note that any PNG files have been purged from the history, and issue numbers have been converted to astrofrog/wcsaxes#... to avoid auto-closing issues).
Is
astropy.visualization.wcsaxesthe right place to put this? Alternatively, it could be a top-level packageastropy.wcsaxesfor more exposure. If we keep it atastropy.visualization.wcsaxes, do we still want to consider having it in the top-level package list anyway?How should we deal with the optional Matplotlib dependency? It's hard to hide away all the imports inside classes, so should we simply raise an error if astropy.visualization.wcsaxes is imported?
Are people happy to say that we support the last two stable releases of Matplotlib? (this is important for CI testing)
Things that need doing before this is merged
astropy.utils.dataThings that can be done after this is merged
Details
This merge preserves the full version history of WCAxes. To do this, I made a special branch in the WCSAxes repo which has all the files moved to the correct position and all the imports updated for instance: https://github.com/astrofrog/wcsaxes/tree/astropy-merge
I am then adding a few more commits in this PR that relate to updating Astropy following the merge. The merge was done with
I also did some things in the astropy-merge branch to get rid of PNG files in the history and also changed any issue numbers in commit messages to explicitly point to
astrofrog/wcsaxes#...to avoid auto-closing issues. I will write up the whole process after this is merged (if it is).