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/3981#issuecomment-985824018,https://api.github.com/repos/pydata/xarray/issues/3981,985824018,IC_kwDOAMm_X846wnsS,2443309,2021-12-03T20:59:27Z,2021-12-03T20:59:27Z,MEMBER,@andy-sweet - please do join the next call. I've added it to the meeting agenda. ,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-985051449,https://api.github.com/repos/pydata/xarray/issues/3981,985051449,IC_kwDOAMm_X846trE5,2443309,2021-12-02T22:25:29Z,2021-12-02T22:25:39Z,MEMBER,"Hi @sofroniewn - This is certainly something we still want to work on (see [this section of our current roadmap](http://xarray.pydata.org/en/stable/roadmap.html#labeled-array-without-coordinates) and a [more detailed proposal that included work in this area](https://doi.org/10.5281/zenodo.5484175)). I actually think the relevant part of the linked proposal is the best we have for a working plan here (text copied from doc below):
> ### Xvariable: New lightweight Variable API (labeled arrays without coordinates)
> This work area is about cleaning up Xarray’s internals, and allowing our low-level “Variable” data structure to be usable by other projects in the scientific Python ecosystem. We have identified the following key tasks and deliverables:
>
> a. Formalize Xarray’s contract for valid data inside “Variable”, and remove/replace some legacy features that would be hard to justify for a generic library:
> 1. Move the “encoding” attribute from “Variable” onto a new “duck array” class that can be used inside a “Variable” (#5082)
> 2. Expose Xarray’s internal model for “explicit array indexing” as a public API. Xarray uses this feature because supporting the full complexity of NumPy’s full indexing API is hard for many array implementations.
>
> b. Separate out and possibly rename/re-brand to Xvariable parts of Xarray internals into new projects. This will increase their visibility, find new users for these tools and improve the maintainability of Xarray itself.
> 1. The ”Variable” class will move into a separate project that only depends upon NumPy, and that Xarray in-turn will depend upon. We hope this project will be of interest to users interested in simpler tools than Xarray (#3981).
> 2. The new package will support indexing and a limited series of other operations lazily on arrays loaded from disk or remote storage, without loading the entire array into memory. This project is of interest to other projects such as Napari (#5081).
>
> c. API stabilization, code consolidation and maintenance of the external project.
We have a bi-weekly developer call on Wednesday mornings (#4001), one idea would be devote 10-15 minutes of our next meeting to this topic. Is that something you and/or @andy-sweet would be up for joining?
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-877464691,https://api.github.com/repos/pydata/xarray/issues/3981,877464691,MDEyOklzc3VlQ29tbWVudDg3NzQ2NDY5MQ==,1217238,2021-07-09T21:25:25Z,2021-07-09T21:25:25Z,MEMBER,"We wrote a proposal to build an ""xarray-lite"" as part of a recent CZI
application. We're still waiting to hear back, but if that's funded we'd
definitely love to work with you on this.
On Fri, Jul 9, 2021 at 12:16 PM Matthew Brett ***@***.***>
wrote:
> We were just talking about this over at https://github.com/nipy/nibabel -
> because we are about commit ourselves to an array-axis-labelling API. Is
> xarray-lite on the near or the distant horizon? Should we wait, to make
> our decisions? Mentioning @effigies because
> he reminded me about this thread.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or
> unsubscribe
>
> .
>
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-808791582,https://api.github.com/repos/pydata/xarray/issues/3981,808791582,MDEyOklzc3VlQ29tbWVudDgwODc5MTU4Mg==,13301940,2021-03-27T19:36:37Z,2021-03-27T19:36:37Z,MEMBER,"> Perhaps we could all this xarr to denote a minimal version of xarray, unless that's too punny?
I've heard folks referring to this proposal as `xarray-lite`, and I think it'd be a good name, too.
","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-808677644,https://api.github.com/repos/pydata/xarray/issues/3981,808677644,MDEyOklzc3VlQ29tbWVudDgwODY3NzY0NA==,1217238,2021-03-27T07:18:23Z,2021-03-27T07:18:23Z,MEMBER,"Thinking about this a little more, I would lean towards the separate package that xarray could depend upon. Perhaps we could all this `xarr` to denote a minimal version of `xarray`, unless that's too punny?","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-665812548,https://api.github.com/repos/pydata/xarray/issues/3981,665812548,MDEyOklzc3VlQ29tbWVudDY2NTgxMjU0OA==,1217238,2020-07-29T17:58:50Z,2020-07-29T17:58:50Z,MEMBER,"> BUT @shoyer has been consistent against making Variable public, so maybe the best option is to fork it out to `xarray-contrib/variable`?
`Variable` is a public API, which just don't encourage it for (most) users.
I think it would be relatively straightforward to expose `xarray.Variable` without the pandas dependency. We currently use pandas a little bit for input normalization in `Variable` and methods like `isnull()`, but we could likely add slower fallback option (or just not expose these features unless pandas is installed).","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-665746983,https://api.github.com/repos/pydata/xarray/issues/3981,665746983,MDEyOklzc3VlQ29tbWVudDY2NTc0Njk4Mw==,2448579,2020-07-29T15:52:17Z,2020-07-29T15:57:00Z,MEMBER,"Another possible outcome is that pandas becomes optional as part of the indexing refactor, and we expose Variable as public API.
BUT @shoyer has been consistent against making Variable public, so maybe the best option is to fork it out to `xarray-contrib/variable`?
EDIT: The git log for `variable.py` shows really minor changes over the past year or two (https://github.com/pydata/xarray/commits/master/xarray/core/variable.py) — mostly adding new method (e.g. pad & quantile) and some NEP-18 work. So it seems pretty stable and perhaps not much effort to exchange future patches between xarray and the fork.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-665730527,https://api.github.com/repos/pydata/xarray/issues/3981,665730527,MDEyOklzc3VlQ29tbWVudDY2NTczMDUyNw==,5635139,2020-07-29T15:23:09Z,2020-07-29T15:23:09Z,MEMBER,"What would the options be for moving this forward?
- Try / Except import blocks, like we do for other libraries
- A separate package (could be in the same repo though)
- ?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880
https://github.com/pydata/xarray/issues/3981#issuecomment-615494816,https://api.github.com/repos/pydata/xarray/issues/3981,615494816,MDEyOklzc3VlQ29tbWVudDYxNTQ5NDgxNg==,2443309,2020-04-17T22:40:59Z,2020-04-17T22:40:59Z,MEMBER,"Thanks @amueller! You're not the only group that has voiced interest in an index-free labeled array so I think its still worth discussing.
> I think right now we're most concerned about sparse data representations (and I was considering asking you folks if you'd support scipy.sparse ;
We have recently added support for [pydata/sparse](https://sparse.pydata.org/en/latest/). We need to document this better (#3484). This work is not 100% complete (https://github.com/pydata/xarray/issues/3213) and is part of Xarray's larger goal of [supporting duck arrays](https://github.com/pydata/xarray/projects/2). Please chime in on one of those issues so we can go a bit deeper.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,602256880