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/issues/1850#issuecomment-359972620,https://api.github.com/repos/pydata/xarray/issues/1850,359972620,MDEyOklzc3VlQ29tbWVudDM1OTk3MjYyMA==,4160723,2018-01-23T23:54:33Z,2018-01-23T23:55:02Z,MEMBER,"To make methods even more discoverable, we might also add the `x` prefix to `DataArray` or `Dataset` accessors. This would work quite well with auto-completion, even though `x` alone is very often used as coordinate. Like suggested in #1447, we could have something like

```
$ conda install xarray-scipy -c conda-forge`
```

```python
>>> import xarray as xr
>>> import xscipy
```

```python
>>> da = xr.DataArray(...)
>>> da.xscipy.method()
```

But maybe that's too much `x`...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-359969044,https://api.github.com/repos/pydata/xarray/issues/1850,359969044,MDEyOklzc3VlQ29tbWVudDM1OTk2OTA0NA==,4160723,2018-01-23T23:36:23Z,2018-01-23T23:36:23Z,MEMBER,"> should it be in just one repository or in many?

One repository for all contrib projects would be hard to maintain if we allow very specific projects, like a little xarray extension to work with the 'xyz' GCM model (which seems to be a common case for extensions). That said, it doesn't prevent us from adding bigger, generic repositories like `xarray-scipy`.

> but the sklearn-contrib packages are not that discoverable IMO.

Hence the suggestion to choose some convention for package naming, e.g., something similar to `dask` related packages: `dask-learn`, `dask-glm`, `dask-xgboost`, etc.

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-359643132,https://api.github.com/repos/pydata/xarray/issues/1850,359643132,MDEyOklzc3VlQ29tbWVudDM1OTY0MzEzMg==,4160723,2018-01-23T01:50:23Z,2018-01-23T01:50:23Z,MEMBER,"Some additional thoughts:

One thing that I like with contrib modules ""protected"" within the xarray namespace is that it would really help us choosing module names that are short, relevant and ideally the same that the `Dataset` or `DataArray` accessors they provide.

However, it is likely that contrib modules may need domain-specific dependencies other than the ones used in xarray ""core"".  With the `xarray.contrib` model we may end up with a lot of optional dependencies, which may be annoying, e.g., for ci or packaging with conda-forge. To me it would be too restrictive not allowing such specific dependencies in contrib projects.

","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053
https://github.com/pydata/xarray/issues/1850#issuecomment-359637860,https://api.github.com/repos/pydata/xarray/issues/1850,359637860,MDEyOklzc3VlQ29tbWVudDM1OTYzNzg2MA==,4160723,2018-01-23T01:21:42Z,2018-01-23T01:23:08Z,MEMBER,"I like the idea of regrouping contrib projects.

I'd be +1 for the ""separate repository"" model, which looks indeed easier from a maintenance perspective. However, with this model it might probably be a good thing to also follow some package naming convention (see #1447 for discussion) so that we could easily identify contrib projects in, e.g., `import` statements or with package managers. I don't have strong opinion on this, though. Maybe it is too restrictive... 

> ... which ensures that all the contrib packages share a common interface.

I'd see xarray contrib packages mainly provide `Dataset` or `DataArray` accessors that are too domain-specific to be added as ""core"" methods.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,290593053