Separate yt.units into its own package, unyt
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
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
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
+1 for the idea!
On Wed, Mar 28, 2018 at 3:18 PM, Britton Smith brittonsmith@gmail.com wrote:
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
yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
I like this idea -- seems super useful.
On Wed, Mar 28, 2018 at 6:47 PM, Bili Dong - Gmail qobilidop@gmail.com wrote:
+1 for the idea!
On Wed, Mar 28, 2018 at 3:18 PM, Britton Smith brittonsmith@gmail.com wrote:
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
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
Fantastic idea. I was happily kludging units out if yt earlier this week, a stand alone would be super useful.
Sent from my pocket by accident.
On Mar 28, 2018, at 9:40 PM, Michael Zingale michael.zingale@stonybrook.edu wrote:
I like this idea -- seems super useful.
On Wed, Mar 28, 2018 at 6:47 PM, Bili Dong - Gmail qobilidop@gmail.com wrote: +1 for the idea!
On Wed, Mar 28, 2018 at 3:18 PM, Britton Smith brittonsmith@gmail.com wrote: 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
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
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
Thanks for all of your encouragement. The repository is now live at https://github.com/yt-project/unyt.
I'll be making a release soon, I just need to add better documentation and set up doc builds on either travis or readthedocs
-Nathan
On Thu, Mar 29, 2018 at 7:56 AM, D Collins dcollins4096@gmail.com wrote:
Fantastic idea. I was happily kludging units out if yt earlier this week, a stand alone would be super useful.
Sent from my pocket by accident.
On Mar 28, 2018, at 9:40 PM, Michael Zingale <michael.zingale@stonybrook. edu> wrote:
I like this idea -- seems super useful.
On Wed, Mar 28, 2018 at 6:47 PM, Bili Dong - Gmail qobilidop@gmail.com wrote:
+1 for the idea!
On Wed, Mar 28, 2018 at 3:18 PM, Britton Smith brittonsmith@gmail.com wrote:
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
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
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 <(631)%20632-8225> *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
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
I like this idea, but I have to admit I am not crazy about “unyt” for a name....
Wait, as I was typing I get it now. “unit” --> “unyt”....
I’ll go back to my corner now.
On Mar 28, 2018, at 5: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 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 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
participants (7)
-
Bili Dong - Gmail -
Britton Smith -
D Collins -
John ZuHone -
Matthew Turk -
Michael Zingale -
Nathan Goldbaum