issues: 234658224
This data as json
id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
234658224 | MDU6SXNzdWUyMzQ2NTgyMjQ= | 1447 | Package naming "conventions" for xarray extensions | 4160723 | closed | 0 | 5 | 2017-06-08T21:14:24Z | 2019-06-28T22:58:33Z | 2019-06-28T21:58:33Z | MEMBER | I'm wondering what would be a good name for a package that primarily aims at providing an xarray extension (in the form of a I'm currently thinking about using a prefix like the For example, for a xarray extension for signal processing we would have: package full name: ```python
The main advantage is that we directly have an idea on what the package is about. It may be also good for the overall visibility of both xarray and its 3rd-party extensions. The downside is that there is three name variations: one for getting and installing the package, another one for importing the package and again another one for using the accessor. This may be annoying especially for new users who are not accustomed to this kind of naming convention. Conversely, choosing a different, unrelated name like salem or pangaea has the advantage of using the same name everywhere and perhaps providing multiple accessors in the same package, but given that the number of xarray extensions is likely to grow in a next future (see, e.g., the pangeo-data project) it would become difficult to have a clear view of the whole xarray package ecosystem. Any thoughts? |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1447/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | 13221727 | issue |