html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/pull/7000#issuecomment-1261359689,https://api.github.com/repos/pydata/xarray/issues/7000,1261359689,IC_kwDOAMm_X85LLtJJ,35968931,2022-09-28T19:16:04Z,2022-09-29T21:38:09Z,MEMBER,"> 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)","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1247111973,https://api.github.com/repos/pydata/xarray/issues/7000,1247111973,IC_kwDOAMm_X85KVWsl,35968931,2022-09-14T17:52:12Z,2022-09-14T17:52:12Z,MEMBER,"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.
","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1244529390,https://api.github.com/repos/pydata/xarray/issues/7000,1244529390,IC_kwDOAMm_X85KLgLu,35968931,2022-09-12T21:40:06Z,2022-09-12T21:43:34Z,MEMBER,"> 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.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1243873325,https://api.github.com/repos/pydata/xarray/issues/7000,1243873325,IC_kwDOAMm_X85KJAAt,35968931,2022-09-12T15:01:07Z,2022-09-12T15:01:07Z,MEMBER,">  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"".","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1243754342,https://api.github.com/repos/pydata/xarray/issues/7000,1243754342,IC_kwDOAMm_X85KIi9m,35968931,2022-09-12T13:35:37Z,2022-09-12T13:35:37Z,MEMBER,"> 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?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1240920968,https://api.github.com/repos/pydata/xarray/issues/7000,1240920968,IC_kwDOAMm_X85J9vOI,35968931,2022-09-08T16:05:01Z,2022-09-08T16:09:05Z,MEMBER,"> 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 :/","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843
https://github.com/pydata/xarray/pull/7000#issuecomment-1240883537,https://api.github.com/repos/pydata/xarray/issues/7000,1240883537,IC_kwDOAMm_X85J9mFR,35968931,2022-09-08T15:34:11Z,2022-09-08T15:34:11Z,MEMBER,"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

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1363829843