Make gv an alias for hv in general?

GeoViews provides specialized versions of many of the components available in HoloViews, and in many cases a given HoloViews object “hv.X” can be used in a projection-aware way as “gv.X”. However, many items in HoloViews can be used as-is with GeoViews, and thus there is not in general a full set of “gv.” versions of the various bits of HoloViews. In practice, it can be difficult for a GeoViews user to remember whether some component has been implemented in GeoViews or in HoloViews, and the resulting code is also often confusing (why does it sometimes say “hv.” here, and “.gv” over here?).

I propose that we consider the alternative approach of mirroring all the main items in '.hv" so that they appear in “.gv” if they make sense there, which will make the user not have to worry about where that component was defined, and will make it simpler for us to add GV-specific versions of HV components later.

The first component that comes to mind is hv.extension(), which needs to be in any GV notebook, thus forcing a direct import of HoloViews. If that function were imported into the geoviews namespace, then users could just call gv.extension(), and someday if we wanted to add some GV-specific extension arguments we could easily do so.

[philippjfr]

Now done. Here’s the full API that’s exposed:

from holoviews import (extension, help, opts, output, renderer, Store, # noqa (API import)
                       Cycle, Palette, Overlay, Layout, NdOverlay, NdLayout,
                       HoloMap, DynamicMap, GridSpace, Dimension)

[jbednar]

I think the container types should be exposed in gv, both for practical reasons for geoviews users and as a declaration that these containers already have full support for all GeoViews functionality.