Repository: sunpy/sunpy

Issue:
Remove sunpy.instr.aia.aiaprep
The `aiaprep` function should be removed from the `sunpy.instr` subpackage. Any AIA specific functionality should transition to the new [`aiapy` package](https://gitlab.com/LMSAL_HUB/aia_hub/aiapy).

This is part of the broader goal of moving instrument-specific functionality out of the core sunpy package and into affiliated packages.


Discussion:
We'd have to go through a deprecation period before removal.  What's the planned timeline for `aiapy`?

A related question: what about `AIAMap`?  Should `aiapy` own that?
I agree this should happen. I would want a release of aiapy to exist before we do this, so that the deprecation warning can point people to the new thing.

 > A related question: what about AIAMap ? Should aiapy own that?

I am not in favour of this. I would want core to be able to open files from as many instruments as possible without needing extra packages.
> > A related question: what about AIAMap ? Should aiapy own that?
> 
> I am not in favour of this. I would want core to be able to open files from as many instruments as possible without needing extra packages.

It depends on how you define "open files".  We'd always be able to open arbitrary FITS files in some default manner.  The issue is that, by retaining `AIAMap`, we take responsibility for interpreting the header properly (e.g., the whole observer-coordinate business), plus we wouldn't be able to offer users the latest orientation calibration (in the case of stale headers).

Furthermore, what if an instrument wants to own their `Map`-derived class?  What if `aiapy` wants to have a `Map` class that does stuff like auto-detect needing to run `aia_prep`?  Do they hack SunPy's `AIAMap` as they import?  Do they replace the whole class?  Do they offer an alternative class (e.g., `TrueAIAMap`)?  All of the above seem undesirable to me.
> We'd have to go through a deprecation period before removal. What's the planned timeline for aiapy?

👍 

> I agree this should happen. I would want a release of aiapy to exist before we do this, so that the deprecation warning can point people to the new thing.

There's not really a strict timeline either for development of the package or for a formal release of `aiapy`. Tentatively I would say there will be release (v0.1) in the next six months, but it could be sooner. I will update here as I know more.

> Furthermore, what if an instrument wants to own their Map-derived class? What if aiapy wants to have a Map class that does stuff like auto-detect needing to run aia_prep? Do they hack SunPy's AIAMap as they import? Do they replace the whole class? Do they offer an alternative class (e.g., TrueAIAMap)? All of the above seem undesirable to me.

I agree that instrument-specific tweaks should not be the responsibility`sunpy` core and I can definitely envision this scenario of many alternative diverging map implementations. However, the same may happen if instrument-specific map classes are farmed out to (future) instrument-specific affiliated packages. This is a much larger discussion and really deserves its own issue(s). At least in the short term, I do not think `aiapy` should own `AIAMap`.

For what it is worth, in `aiapy`, the current preferred approach is to make all of these things (e.g. aiaprep, header fixes, etc) explicit, i.e. the user has to pass their map to a function and get a corrected map out rather than having these things done "automagically" at import. For example, see [this issue](https://gitlab.com/LMSAL_HUB/aia_hub/aiapy/issues/14).
There's currently [a PR to the aiapy repo to implement aiaprep](https://gitlab.com/LMSAL_HUB/aia_hub/aiapy/merge_requests/23). It is essentially the exact version that is in `sunpy/instr/aia.py` though it also addresses #3307. I suspect it will be merged within a week or less.
In light of SEP-0009, does this mean that a deprectation warning cannot be added until v2.0 and then the actual bit of code cannot be removed until v3.0?
We can add a deprecation warning at any time, and it has to be in the code for at least one LTS (i.e for the 2.0 release). So if you added it now, the deprecation warning would be in 1.1, 2.0 and then we can remove the code before 2.1 (so in ~1 year).

I wouldn't want to merge a deprecation warning until aiapy has an official release though (deprecation warnings should always present a currently available way of not getting the warning).
Ok that sounds good.

I don't have a definite timeline for an aiapy release yet, but ideally it will happen before the end of the year. Not sure if that will be before v1.1 or not.
Planning on getting 1.1 out the door no later than the end of Oct.

Resolving patch:
diff --git a/sunpy/instr/aia.py b/sunpy/instr/aia.py
--- a/sunpy/instr/aia.py
+++ b/sunpy/instr/aia.py
@@ -7,10 +7,13 @@
 import astropy.units as u
 
 from sunpy.map.sources.sdo import AIAMap, HMIMap
+from sunpy.util.decorators import deprecated
 
 __all__ = ['aiaprep']
 
 
+@deprecated("2.0", alternative="`register` in aiapy (https://aiapy.readthedocs.io) for converting \
+AIA images to level 1.5")
 def aiaprep(aiamap):
     """
     Processes a level 1 `~sunpy.map.sources.sdo.AIAMap` into a level 1.5
@@ -18,7 +21,8 @@ def aiaprep(aiamap):
 
     Rotates, scales and translates the image so that solar North is aligned
     with the y axis, each pixel is 0.6 arcsec across, and the center of the
-    Sun is at the center of the image. The actual transformation is done by Map's `~sunpy.map.mapbase.GenericMap.rotate` method.
+    Sun is at the center of the image. The actual transformation is done by Map's
+    `~sunpy.map.mapbase.GenericMap.rotate` method.
 
     This function is similar in functionality to ``aia_prep`` in SSWIDL, but
     it does not use the same transformation to rotate the image and it handles


Test patch: