issue_comments: 816173649

This data as json

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/5033#issuecomment-816173649 https://api.github.com/repos/pydata/xarray/issues/5033 816173649 MDEyOklzc3VlQ29tbWVudDgxNjE3MzY0OQ== 226037 2021-04-08T20:41:29Z 2021-04-08T20:41:29Z MEMBER

The first comment is that I see the point of the feature at a theoretical level, but I'm at the third external backend that I'm writing and I didn't miss it. Adding an entrypoint is very easy and works seamlessly during development. Do you have in mind any use case where this is more convenient than adding an entrypoint?

I simply want to do:

```python from custom_backend import engine

ds = xr.load_dataset(filename, engine=engine) ```

That is much simpler than having to figure out what the How to register a backend is talking about. Because I'm a user who doesn't have any grand dreams (yet?) of creating public backend modules I therefore don't see the point in having to do all this extra paperwork.

Well, based on the amount of complexity a developer needs to master in order to write the backend, I would consider the registration to be a relatively trivial bit, especially because the syntax is the same as for the well known console_script.

On one hand I judge the feature to be relatively simple to support in the long long term, on the other hand I still feel that its benefit will be be quite marginal. Therefore I'm still a mild -1.

... we ask backend developers to inherit from BackendEntrypoint, for the sake of consistency I would enforce it here as well, instead to use duck-typing.

That's not how I read the docs. If this is how we actually want it then some words in it should be replaced with "must" and "requires".

But I don't think that should be such a hard requirement when a user insists on using a custom engine this way. I see it as an advanced option where it's the users responsibility to make sure that the engine class has

  • the open_dataset method
  • the open_dataset_parameters attribute
  • the guess_can_open method

Which is very simple to do, see the test for an example. Subclassing using BackendEntrypoint adds complexity and readability issues so I want to at least feel a little motivated to use it but there's nothing fancy going on there, is there any plans?

On this one I can side with you. The initial proposal from @aurghs and myself was to use a dict 😄 .

This one is a higher lever design decisione, I think @jhamman and @shoyer need to weight in.

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