issue_comments

Does anyone know if the backentrypoints are supposed to have an available attribute?

Looks like they are - every subclass of BackendEntryPoint seems to define .available. In each case it points to the corresponding has_[package] flag. I think it might be safe to set .available to default to True in the base class? That way if the backend requires no special dependencies it would by default return True. If we think that makes sense then I'm happy to add a commit doing that so this can be merged.

EDIT: (Actually we should wait to put tests in too really)

We discussed this with Jessica in the xarray community meeting today and I think the conclusion was to return a dict of backend objects with nice reprs to begin with, and if there is appetite then prettify it later, likely with a custom mutable mapping with special repr.

If the dict repr from list_engines is still not good enough maybe replacing the dict with a custom MutableMapping with a good repr format could be a way forward?

I like this idea more than using a pd.dataframe, which is quite a heavy dependency to use for just displaying some strings. (We have other plans to eventually make pandas an optional import too). That would also be consistent with the approach we use for ds.coords and similar.

EDIT: This would also be a good thing to split out into an (optional) future PR though, and merge returning a dict of objects with nice individual reprs for now.

We can certainly change the name of avail_engines() to display_backends(). Is there then a dev need to have another version of list_backends(), or would a "see also" to list_engines() be a solution here?

I think exposing a backends.display_backends() (defined in backends.api like BackendEntrypoint is) and then also pointing from there to the lower-level xr.backends.plugins.list_engines() would be great. That way there is only one more function listed in xarray's main API docs, and list_backends can be for dev use if necessary.

Expanding on that, we could put display_backends in the API docs under IO / conversion and add list_backends under Advanced API. That would keep distinct the two use cases of (1) "I'm a user and want to know what backends are installed for use as engine=...", and (2) "I'm a developer who is trying to add a new backend and I want to see all the actual BackendEntrypoint objects".

Agreed. I added a str to the BackendEntrypoint class, but...

This is helpful already, thank you.

Does it need to be the same method? Why not a method that simply returns a list of classes and another method that prints a nicely formatted list?

I guess not, but we also probably don't want to pollute xarray's public namespace with multiple functions that do basically the same thing. Though maybe as it's all behind the backends namespace that doesn't matter so much? Then we might have list_backends and display_backends or something?

That would not display in a nice table though. But might be anyway nice to add ;)

So what would the return type need to be to get a nice table representation, but also allow you to select out individual backend objects? A pandas object containing the backend objects? Some kind of BackendList class?

What about type(self).__name__

Correct me if I'm wrong, but if a subclassed ZarrBackend object was added as an entrypoint under the key "zarr", wouldn't type(self).__name__ return "ZarrBackend" rather than "zarr", even though "zarr" is what the user would actually have to pass to the engine kwarg of open_dataset to use that backend? Not ideal :/

Hey @JessicaS11! Nice to see you here. This is a going to be a great first-time contribution!

I know that it is more work but I think it would be more beneficial to have this information formated nicely than simply returning some lists. Maybe similar to a pandas dataframe?

One approach might be to add a nice __str__, __repr__, (or even _repr_html_) to the BackendEntrypoint class. That way printing a list (or better a dict) of the engine-specific subclasses would automatically look decent. Something roughly like

```python class BackendEntryPoint: ...

def __str__(self) -> str:
    txt += self.backend_description
    if self.backend_url:
        txt += f"\nFind more info at {self.backend_url}"
    return txt

```

What might be clearer is if this backend class knew it's own name, but I'm not sure it can, hmmm