Modularize Quantity helpers, ensuring scipy.special and erfa are loaded on demand

[mhvk]

This PR has two purposes. The main one is to ensure that scipy.special is only loaded on demand, so that for a typical situation in which astropy is used but scipy.special is not, the latter does not get imported unless one of its functions are actually applied to a Quantity. This helps reduce the import time of astropy.units quite a bit (see below). The second purpose is to split up the very large quantity_helpers file into more manageable pieces, by making it a module.

Note that as part of this, it is becoming possible to "register" sets of ufuncs with the units module without actual loading - I hope to use this this is already used here for erfa, but it could be exposed as well. I've not written any documentation for that yet, as I first want to be sure people agree the structure makes sense (also, it sets the format for the helper functions in stone, which I'm not sure I like).

Excerpts from python -X importtime -c 'import astropy.units:

# With current master
import time: self [us] | cumulative | imported package
import time:       787 |      60205 |       scipy.special
import time:       419 |      69729 |     astropy.units.quantity_helper
import time:      4641 |      76212 |   astropy.units.quantity
import time:     20671 |     521538 | astropy.units
# With this PR
import time:       216 |        216 |       astropy.units.quantity_helper.converters
import time:       310 |        310 |       astropy.units.quantity_helper.helpers
import time:       183 |        183 |       astropy.units.quantity_helper.scipy_special
import time:       225 |        932 |     astropy.units.quantity_helper
import time:      5404 |       8088 |   astropy.units.quantity
import time:     19827 |     432185 | astropy.units

[astropy-bot]

Hi there @mhvk 👋 - thanks for the pull request! I'm just a friendly 🤖 that checks for issues related to the changelog and making sure that this pull request is milestoned and labeled correctly. This is mainly intended for the maintainers, so if you are not a maintainer you can ignore this, and a maintainer will let you know if any action is required on your part 😃.

Everything looks good from my point of view! 👍

If there are any issues with this message, please report them here.

[mhvk]

This becomes an unnecessary link, but keeping it for backwards compatibility (currently, it is also still being used in helpers for unsupported numpy ufuncs; can update that to use setting to None instead if people like this whole PR).

[mhvk]

circle-ci failure is a false positive - something to do with downloading again, so cc @pllim and @bsipocz.

[pllim]

Re: CircleCI -- The error suggests something funky is going on with the cache lock in that CircleCI run. If restarting it makes it go away, I am not sure how to debug it... 🤷‍♀️

[pllim]

This needs a rebase anyway. Let's see if CircleCI fixes itself...

[mhvk]

OK, rebased... Hopefully things will pass now.

[pllim]

Travis is still running but CircleCI already passed. Not sure what caused the previous failure!

[bsipocz]

@mhvk - I've removed myself from the reviewers, as I'm not familiar enough with units internal to spot anything that you might have overseen.

However, I very much like the general idea of splitting up the helpers and make sure we don't import big things unnecessarily.

[mhvk]

Rebased since erfa had become supported - that is now modularized as well, for those who use units but not coordinates.

[astrofrog]

I'm not an expert on astropy.units but these changes seem worthwhile to me. It's hard to see changes vs code that was moved, so I can't review everything line by line, but I think this is fine.