Astropy Affiliated Package Review

[astrofrog]

This package has been re-reviewed by the Astropy coordination committee in relation to the Astropy affiliated package ecosystem.

We have adopted a review process for affiliated package that includes assigning quantitative ‘scores’ (red/orange/green) for different categories of review. You can read up more about this process here. (This document, currently in Google Docs, will be moved to the documentation in the near future.) For each of the categories below we have listed the score and have included some comments when the score is not green.

Functionality/Scope
No further comments
Integration with Astropy ecosystem
In many places poliastro makes use of astropy constructs like time and units. However, in at least one place it does not use quantity where it could (poliastro.twobody). This might be a hold-over from before Quantity existed, in which case it is fine but might be on the roadmap for updating later on. In addition the docs for poliastro.coordinates say "this module complements astropy.coordinates". It looks like this may pre-date Astropy 2.0 in that it is mostly velocity-related machinery. Would be useful to know if that can be changed to be compatible with the new machinery, but it's not a problem right now because that's a new Astropy feature. But should be on the roadmap for updating (or updating astropy.coordinates if it isn't suitable for poliastro's needs)
Documentation
No further comments
Testing
Coverage could be improved a bit
Development status
Recent releases feature some backwards-incompatible changes, so we are classifying this as under "heavy development". However, we can change this to good if the plan is to have more stable releases in future.
Python 3 compatibility
No further comments

Summary/Decision: Things are looking good, and this package meets the review criteria for
affiliated packages, so we are happy to confirm that we'll be listing your
package as an affiliated package! Keep up the good work, and we encourage you to
improve on the areas above that weren't “green” yet.

If you agree with the above review, please feel free to close this issue. If you have any follow-up questions or disagree with any of the comments above, leave a comment and we can discuss it here. At any point in future you can request a re-review of the package if you believe any of the scores should be updated - contact the coordination committee, and we’ll do a new review. Note that we are in the process of redesigning the http://affiliated.astropy.org page to show these scores (but not the comments). Finally, please keep the title of this issue as-is (“Astropy Affiliated Package Review”) to make it easy to search for affiliated package reviews in future.

[Juanlu001]

Hello @astrofrog, thank you a lot for taking poliastro in consideration! I am extremely happy to have it as an Astropy affiliated package, and this is no doubt a strong motivation to move forward and keep up with the development.

I agree with the "Development status" and "Testing" scores. The former will probably stay throughout 2018 (I expect poliastro to stabilize in 2019) and the latter is a known issue that we have on our radar.

Regarding the integration with the Astropy ecosystem, I have a couple of questions:

However, in at least one place it does not use quantity where it could (poliastro.twobody).

Would you specify a bit more? All modules in poliastro.twobody use astropy.quantity and feature the line from astropy import units as u.

In addition the docs for poliastro.coordinates say "this module complements astropy.coordinates". It looks like this may pre-date Astropy 2.0 in that it is mostly velocity-related machinery.

Let me clarify this :) We have been following closely the development of velocity conversions in Astropy, see: #186 astropy/astropy#6435 astropy/astropy#6436 astropy/astropy#5898 astropy/astropy#6494 but, very specially, this pull request:

astropy/astropy#6508

This proved to be challenging from a "social" point of view and we wanted to have a stable release in October, so our decision was to use poliastro as a "test environment" for things we would like to contribute back to Astropy (and also without the need of very broad consensus while the APIs are changing).

These are mostly comments about the score details but I agree with the review, so I will be glad to close the issue when you have the time to comment on these small questions.

[eteq]

Hi @Juanlu001 - thanks for the engagement! Let me try to answer your questions here:

However, in at least one place it does not use quantity where it could (poliastro.twobody).

Would you specify a bit more? All modules in poliastro.twobody use astropy.quantity and feature the line from astropy import units as u.

This appears to have just been a mistake on my part (I'm the one who wrote that comment) - I looked at several functions and thought it wasn't quantity-compliant but looking more closely, all the ones I saw before are called from other places that do have quantities. So you can ignore that. (If you like you can take this as very mild feedback that some of the docstrings in twobody aren't explicit in showing the units of the inputs... But that's not an "astropy integration" problem, just a minor suggestion for your docstrings.)

Let me clarify this ...

Great! That all makes sense, and is a very sensible approach. We just have to be sure we keep the communication lines open in the future.

[Juanlu001]

Thanks a lot for your response @eteq! I'm definitely closing this issue :)