Hi all, I had a request today to make yt.units its own package. Right now if someone wants to use yt.units in their own package, they need to depend on *all* of yt. That's quite a lot of code to depend on if all you want is an ndarray subclass that knows about units. From the beginning, I've tried to make yt.units *not* depend on the rest of yt as much as possible. For this reason it's relatively simple as far as code modifications go to extract yt.units into it's own package. This afternoon I've done most of that work and have created a new package called "unyt" (pronounced the same as unit). For now the code lives as a repo owned by my github account: https://github.com/ngoldbaum/unyt I'd like to create a new repository in the yt-project github organization named unyt as a place for this code to live: https://github.com/yt-project/unyt For now I'm *not* working towards making yt depend on unyt - effectively I've forked yt.units into a new package. I've attempted to keep the existing git history for the new package though, so you may find that you have commits in this new package that originated in yt. This *does* effectively double the maintenance burden for yt.units, since now I need to make sure that yt.units and unyt don't diverge too much. However, the pace of changes to yt.units is pretty slow these days so I'm not overly worried about creating a bunch of work for myself. Eventually we could consider making yt depend on unyt and making yt.units a compatibility shim, however I don't think we want to take that step yet. So far I've only made changes necessary to get unyt isolated from the rest of yt. I've also renamed a few things. For example, YTArray is now unyt_array and YTQuantity is now unyt_quantity. I'm curious whether anyone has a problem with creating a repo on the yt-project org for unyt to live in. If so, please let me know so we can hash it out. Please also let me know if you have any other questions or concerns about the course of action outlined above. -Nathan