Reconsider the name of this package

[rgommers]

The name of this package is "Sparse" according to the docs and readme, that's basically not searchable or usable. I've been referring to it as "PyData Sparse", which is also a weird name for a package.

Can we reconsider this and come up with a name that's consistent and searchable?

[hameerabbasi]

How about python-sparse or scipy-sparse?

[rgommers]

ndsparse ?

[hameerabbasi]

There's also the related issue: Do we change the name on PyPI and the repository name, or just the readme and the documentation for better searchability?

[perimosocordiae]

Github has very nice support for repository renaming, with automatic forwarding of old links to the new name. I've moved repos around with zero issues.

Not sure about the story from PyPI, though.

[shoyer]

I would suggest renaming the PyPI package and repository name. It's a little annoying to migrate but better than having inconsistent names.

For renaming xray -> xarray, I uploaded a final release of xray to PyPI with a new README pointing to the new package: https://pypi.org/project/xray/

I also made import xray issue a DeprecationWarning, suggesting to users that they may want to switch.

[ivirshup]

I'm not sure I understand the impetus for renaming.

I think sparse is a good name for a sparse matrix library (and a great get, would've expected it to be taken). sparse_arrays would be a close second for me.

It's nice when a foundational package can have short, descriptive name.

I don't agree it's hard to search for. It's the second result on google for "python sparse" and third on duck-duck-go at the moment (scipy.sparse being the top), and I'm not sure what other search terms would be used.

Plus the name collision with scipy.sparse (the only time I've run into confusion) should go away in the future right?

---

As an aside, xray -> xarray makes sense to me, since one might assume xray has something to do with medical imaging or physics. This seems much less likely with sparse.

[hameerabbasi]

Copying here for visibility, I'm open to keeping the name the same, but there will need to be a version 2.0 with TACO-based rewrites, including some possible NaN-related breaks. See #460 (comment).