Spin off Constants, Quantities, and Units as a separate project

[MarkWieczorek]

Astropy has come up with a useful way of dealing with variables that have units by defining the Constant, Quantity and units classes. These classes would be very useful for many fields of science outside of astronomy. In particular, in the planetary science pyshtools project, we import astropy only to use these classes. I have suggested that another project in the Earth sciences do the same thing, but their initial response was that it would be overkill to import astropy only for these three small things.

Given that astropy is a large project, you might want to consider spinning off a few things into separate projects that would be more accessible to a broader audience. A separate "units", or "quantities" project would be one such possibility.

[pllim]

Units came from another package originally. There were talks in the past about a similar topic but we decided against it. 🤷

[pllim]

To elaborate further, even though on the surface, you only use those few things, under the hood, they also rely on astropy.utils, astropy.config, and the science state machinery. Splitting them out is not a trivial thing to do.

[mhvk]

@MarkWieczorek - As @pllim notes, we definitely considered both splitting out units and possibly using an outside units package. For the latter, I think they're not quite as good :smile:, but splitting out is something I've also toyed with: while we rely on some other pieces of astropy, the reliance is relatively mild (the few utilities could be easily duplicated and there is only one rather unimportant configuration item). And I've done my best to ensure that units and constants do not depend on anything else (the only part where there is a dependence is for making Quantity integrate more easily with astropy.table). So, at least in principle, it is not too hard to make an astropy-units package that includes units, constants, and a few utilities.

But, as always, the real question is for someone finding the time to split it out... Ideally in some way that astropy itself could still simply vendor it, or even better, that development would remain within astropy, but that extraction would be something that happened automatically (with tests to check that it wouldn't break).

I fear I don't really see myself finding time for it, but I'd be willing to help. To get a sense of what would be involved in making it an independent package, we recently split off astropy._erfa - see https://pyerfa.readthedocs.io/en/latest/changelog.html#pyerfa-repository-import-from-astropy (making an independently packaged "copy" or "astropy-units" subpacakge for pypi might be easier; have not thought that through).