We should keep an eye on DataTree and see what can be upstreamed, but I think we should have an azbase accessor defined here where we reimplement some of the methods of InferenceData so they behave in the most similar way possible. For example, I use .map a lot. I basically use it for any operation that needs to be done on multiple groups at once. The closest thing to InferenceData.map would be DataTree.map_over_subtree which clearly does not fit the bill because 1) it has no way of indicating in the function call to which subset of groups the function should be applied to 2) the signature of the function has to be func(node.dataset, *args, **kwargs) -> Datasetand datasets don't have a name attribute so the function can't decide to return the node as is or transform it based on the name.
There are also other methods that differ from general xarray behaviour such as extend or add_groups but that are quite common in use, so having them mimicked via DataTree.azbase.extend or things like this would be nice and would help make the transition easier.
Why azbase or arviz? So far, the idea is to have the splitted pacakges be mostly independent. Thus it should be possible to use them on their own (that is, installing arviz-base but no arviz-stats nor arviz-plotting). However, while we want this to be possible, I don't expect that to be the most common case, so we should also expose a full-fledged arviz. If we use azbase and azstats for the accessors in the splitted packages, the arviz package can then be a mostly metapackage that installs all 3 at the same time, exposes their functions via a common namespace arviz. and could also combine the azbase and azstats accessors into a single arviz accessor.
We should keep an eye on DataTree and see what can be upstreamed, but I think we should have an
azbaseaccessor defined here where we reimplement some of the methods ofInferenceDataso they behave in the most similar way possible. For example, I use.mapa lot. I basically use it for any operation that needs to be done on multiple groups at once. The closest thing toInferenceData.mapwould beDataTree.map_over_subtreewhich clearly does not fit the bill because 1) it has no way of indicating in the function call to which subset of groups the function should be applied to 2) the signature of the function has to befunc(node.dataset, *args, **kwargs) -> Datasetand datasets don't have anameattribute so the function can't decide to return the node as is or transform it based on the name.There are also other methods that differ from general xarray behaviour such as
extendoradd_groupsbut that are quite common in use, so having them mimicked viaDataTree.azbase.extendor things like this would be nice and would help make the transition easier.Why
azbaseorarviz? So far, the idea is to have the splitted pacakges be mostly independent. Thus it should be possible to use them on their own (that is, installing arviz-base but no arviz-stats nor arviz-plotting). However, while we want this to be possible, I don't expect that to be the most common case, so we should also expose a full-fledgedarviz. If we useazbaseandazstatsfor the accessors in the splitted packages, thearvizpackage can then be a mostly metapackage that installs all 3 at the same time, exposes their functions via a common namespacearviz.and could also combine theazbaseandazstatsaccessors into a singlearvizaccessor.