Restrict u.spectral equivalency to contexts where it is required

[dhomeier]

Fix for #671

Fairly pedestrian implementation; @mhvk your proposed solution to use setup_class/teardown_class environments would require creating classes for the tests in question, right?

Leaving this for consideration now; perhaps some discussion is due if the tests now still test what they are supposed to test (i.e. would a user in a normal work environment expect those equivalencies to be in effect as well)?

[dhomeier]

Concerning the failed doctests - need to think of a clean way to make this work in the docs. I am wondering if using equivalencies is really the best way to tackle the problem with lower/upper boundaries in the spectral ranges...

[dhomeier]

Fixing the code rather than the tests hopefully will hold now. Concerning the failed remote_data tests, I got 404 errors from das.sdss.org yesterday roughly 2 out of 3 times.

The local astropy tests seem to succeed now at least without any failures potentially related to astropy/astropy#10283.
@nmearl I've had a second look for any other equivalency uses that would depend on u.spectral set and might not be fully covered by the tests; u.is_equivalent checks for spectral_axis type quantities in fitmodels, extract_spectral_region and spectrum_mixin are already doing it the Right Way™*. Can you think of any uses of Unit.to() that might still depend on the equivalency?

*Rather, either one of the two right ways – had forgotten that equivalency can also be passed as an option; for the single operation uses this may be preferable to the with context.

[mhvk]

@dhomeier - answering without looking: yes, setup_class and teardown_class require test classes, but there are also module-level equivalents.

[dhomeier]

@mhvk thanks; since there are only three instances which are also easily managed with the kwarg, I think there is no need for a major restructuring of the tests at this point.

[nmearl]

I've had a second look for any other equivalency uses that would depend on u.spectral set and might not be fully covered by the tests; u.is_equivalent checks for spectral_axis type quantities in fitmodels, extract_spectral_region and spectrum_mixin are already doing it the Right Way™*. Can you think of any uses of Unit.to() that might still depend on the equivalency?

It seems you've covered all the bases here. The failures are due to inconsistencies with upstream currently (since we moved SpectralCoord into astropy proper).

I'm tempted to say that this is good as it stands, as it passes all my use cases currently.

[nmearl]

Thanks @dhomeier!