Also +1 on having yt depend on unyt and hosting under yt-project.  I don't mind the package name "unyt", although "unyts" might also be worth considering, since it came from yt.units.

I also have a number of instances of using just yt.units in scripts, so I think this could be a super useful standalone package for many people.  This is great.

On Wed, Mar 28, 2018 at 2:56 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Awesome work.  +1 on making the new repo under yt-project, and I would
actually be 100% okay with having yt depend on this, since it's pure
python.

On Wed, Mar 28, 2018 at 4:53 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
> 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
>
> _______________________________________________
> yt-dev mailing list -- yt-dev@python.org
> To unsubscribe send an email to yt-dev-leave@python.org
>
_______________________________________________
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org