Gammapy code organisation

This is a first attempt at a diagram to illustrate Gammapy code organisation.

After some discussion / improvements / code re-organisation I plan to add it to the Gammapy docs and the paper.

At the moment it only shows which sub-packages are lower or higher level. The idea is that a given package is only allowed to import from lower-level packages to avoid circular imports. There are some exceptions, like e.g. gammapy.data does import higher-level classes in factory functions using delayed imports. I’m not sure if it’s desirable / possible to try to avoid this completely. One more aspect: e.g. for spectral analysis we probably want to sometimes extract a spectrum out of a diffuse spectral model cube (e.g. for Fermi-LAT), i.e. functions from lower-level modules can take objects from higher-level package as inputs.

Some ideas to make the diagram better:

• Add public sub-sub packages, like gammapy.spectrum.models or all packages in gammapy.utils to the diagram.
• We could try and add a one-line description for each sub-package, although I don’t think this would work well (too much text).
• We could try to draw connecting lines for all dependencies that are actually there (e.g. astro doesn’t depend on most of the lower-level sub-packages. I don’t think this will work well … too many lines.

There’s a lot of work / cleanup to do. I’ll continue with this in a few weeks.

I have one concrete question: OK to dissolve gammapy.morphology, and introducing gammapy.image.models?

[adonath]

👍 to dissolve gammapy.morphology and introduce gammapy.image.models. I think this makes the structure of gammapy more consistent.

[cdeil]

Discussion will continue in #2274