guidelines for when to create extension packages

[keewis]

In order to keep the dask / distributed PR (#1129) focused on that, let's continue the discussion here.

@hgrecco:

I would like to take the opportunity to ask a question: When are we going to provide an external package (e.g. pint-pandas) and when are we going to include it in pint. I am not suggesting to create pint-dask but rather to start building a rationale about pint extensions.

@dopplershift:

My concern with extension packages is that they won't necessarily receive the same level of maintenance as the core pint library. As a maintainer of a downstream library, I'm always concerned about adding more dependencies.

What do people see as the benefits of having external packages?

First of all, external packages do have the advantage of a separate release cycle.

If I'm not missing any, all the extension packages we have right now (pint-pandas and pint-xarray) are for wrapping pint, not the other way around. While the dask interface is not really part of it, pint wrapping other libraries is usually done using the numpy interface (the only exception is measurements / uncertainties).

[jthielen]

If I'm not missing any, all the extension packages we have right now (pint-pandas and pint-xarray) are for wrapping pint, not the other way around. While the dask interface is not really part of it, pint wrapping other libraries is usually done using the numpy interface (the only exception is measurements / uncertainties).

That sounds like it could be a good guideline/rule-of-thumb.

Extension packages like pint-pandas and pint-xarray make the most sense for when Pint is being wrapped and no changes are needed to Pint's core classes. These essentially exist between or on top of two packages, and having the separate packages allows for more flexible iteration and more separation of concerns. On the other hand, integration/compatibility with types that Pint wraps (e.g., Dask and uncertainties) often require interfaces on Pint's core classes, so that they make the most sense to be in Pint proper. If I had to summarize,

• Extension: wrapping Pint -> features independent/on top of the libraries -> separate packages
• Integration: wrapped by Pint -> intermingling of APIs -> built-in

Of course, concerns about new and less-supported dependencies for downstream libraries and also not wanting to bloat the core library still hold and make this less clear.

[hgrecco]

I thought about this for a while and makes complete sense. It would be great if it can be added to the docs, maybe to the contributing code part?