Repository navigation
Package naming "conventions" for xarray extensions #1447
Description
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 DataArray and/or Dataset accessor).
I'm currently thinking about using a prefix like the scikit package family (e.g., scikit-learn, scikit-image).
For example, for a xarray extension for signal processing we would have:
package full name: xarray-signal
package import name: xrsignal (like sklearn)
accessor name: signal.
>>> import xarray as xr
>>> import xrsignal
>>> ds = xr.Dataset()
>>> ds.signal.process(...)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?
Activity
jhamman commentedon Jun 15, 2017
@benbovy -
I don't have really strong opinions here but I can tell you what I've done with xmap. I basically tried to keep it simple and use the same name for all three (package full name, package import name, and the accessor name). My thoughts on how to handle longer names are generally the same, the package-full name could be anything (I'd be okay switching to
xarray-mapping) and I like the idea of having an identifiable collection of extensions (+1 forxarrayprefix). My gut reaction toxrsignalis to drop ther(xsignal) and perhaps to usexsignalas the accessor name as well. Just some thoughts and like I said, no strong opinions here.darothen commentedon Jun 16, 2017
For xbpch I followed a similar naming convention based on @rabernat's xmitgcm. Brewing on the horizon is an xarray-powered toolkit for GEOS-Chem and while it'll be a stand-alone library, I imagine it'll belong to this confederation of toolkits and provide an accessor or two for computing model grid geometries and related things on-the-fly. I'd also +1 for an
xarrayprefix (so,xbpch->xarray-bpchandxmitgcm->xarray-mitgcm?)benbovy commentedon Jun 19, 2017
I like the idea of using only the
xprefix for both the package-import name and the accessor.xrdoesn't look very nice as a prefix with no underscore. Maybe having thexprefix for the accessor as well would also differentiate 3rd-party accessors from xarray-specific accessors likedt?I don't have strong opinions on this either.
spencerahill commentedon Jun 19, 2017
One other thought for
xrather thanxr: to me at least, thex-prefixed package names just sound cool 😄stale commentedon May 29, 2019
In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity
If this issue remains relevant, please comment here or remove the
stalelabel; otherwise it will be marked as closed automatically