issue_comments

Table actions

4 rows where issue = 290593053 and user = 4160723 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • benbovy · 4 ✖

issue 1

  • xarray contrib module · 4 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
359972620 https://github.com/pydata/xarray/issues/1850#issuecomment-359972620 https://api.github.com/repos/pydata/xarray/issues/1850 MDEyOklzc3VlQ29tbWVudDM1OTk3MjYyMA== benbovy 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
}
   xarray contrib module 290593053
359969044 https://github.com/pydata/xarray/issues/1850#issuecomment-359969044 https://api.github.com/repos/pydata/xarray/issues/1850 MDEyOklzc3VlQ29tbWVudDM1OTk2OTA0NA== benbovy 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
}
   xarray contrib module 290593053
359643132 https://github.com/pydata/xarray/issues/1850#issuecomment-359643132 https://api.github.com/repos/pydata/xarray/issues/1850 MDEyOklzc3VlQ29tbWVudDM1OTY0MzEzMg== benbovy 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
}
   xarray contrib module 290593053
359637860 https://github.com/pydata/xarray/issues/1850#issuecomment-359637860 https://api.github.com/repos/pydata/xarray/issues/1850 MDEyOklzc3VlQ29tbWVudDM1OTYzNzg2MA== benbovy 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
}
   xarray contrib module 290593053

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);