You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gridded seeks to provide a single API for working with multiple grid types -- currently triangular ugrid, quad sgrid, and rectangular grids.
It also has code for the vertical coordinates and time.
As UGRID and SGRID have a fair bit in common, it became untenable to try to maintain gridded, pyugrid and pysgrid all independently.
So we merged (copy and pasted..) the pyugrid and pysgrid code into gridded, and are maintaining it there.
I'm always on the fence about when to keep packages separate, and when to merge them together. I think you need to look at it from a couple of perspectives:
Are these packages useful on their own?
In this case, the answer is yes -- which is why they were developed on their own in the first place.
Is there benefit to developing them together?
In this case, the answer also yes -- having been developed pretty independently, pyugrid and pysgid have a fair bit of duplicated code and gratuitously different APIs. Duplicated code is duplicated code -- always bad :-) -- but the different APIs meant is was very hard to write other code that worked with both, which meant heading down the path to even MORE duplicated code.
Finally, is there a downside to keeping them together?
In this case, I think no, there isn't. They are both fairly small, and they have the same dependencies. So it is no harder for someone that only needs one of the packages to install the whole thing, and then use the bits they need.
And it's open source -- folks can contribute to the parts they care about, while ignoring the other parts.
So what does this mean for pyugrid and pysgrid?
We at ERD wrote most of the pyugrid code -- we'll finish a little clean up right now, but are not going to maintain it any further.
pysgrid was written mostly by @ayan-usgs, with extension and maintenance by a few other folks since then.
So it's up to @ayan-usgs and the others to decide what they want to do, but ERD will not be contributing directly to pysgrid any more.
I highly encourage users of pyugrid and pysgrid to come on over and try gridded -- it gives you lots of cool stuff, and more importantly, opens the door to even more. For the most part, you should be able to simply change your imports to:
from gridded import pyugrid
or
from gridded import pysgrid
and have the same functionality you have now. (though there is no guarantee, as we unify the APIs, things WILL change.
But if you check out gridded.Dataset, you'll get a whole lot more...
To be fair, gridded is currently a bit hacked together to support what we need to support -- the API could be cleaner, the code better structured, and it definitely needs better docs and more examples. Plus added functionality!
So come join us and make it a great tool for all of us.
NOTE: we put gridded in the NOAA-ORR-ERD organization, as that's where we put our code. But if it would help make it a more community project, we'd be happy to move it to another org.
I'm open to decommissioning pysgrid in preference for gridded. I haven't had much time to maintain pysgrid, so I think moving to gridded will ensure that the functionality is maintained in the future.
That said, I welcome others to chime in if they feel so moved.
NOTE TO ALL:
We at NOAA-ERD have "moved on" to the gridded project:
https://github.com/NOAA-ORR-ERD/gridded
gridded seeks to provide a single API for working with multiple grid types -- currently triangular ugrid, quad sgrid, and rectangular grids.
It also has code for the vertical coordinates and time.
As UGRID and SGRID have a fair bit in common, it became untenable to try to maintain gridded, pyugrid and pysgrid all independently.
So we merged (copy and pasted..) the pyugrid and pysgrid code into gridded, and are maintaining it there.
I'm always on the fence about when to keep packages separate, and when to merge them together. I think you need to look at it from a couple of perspectives:
In this case, the answer is yes -- which is why they were developed on their own in the first place.
In this case, the answer also yes -- having been developed pretty independently, pyugrid and pysgid have a fair bit of duplicated code and gratuitously different APIs. Duplicated code is duplicated code -- always bad :-) -- but the different APIs meant is was very hard to write other code that worked with both, which meant heading down the path to even MORE duplicated code.
In this case, I think no, there isn't. They are both fairly small, and they have the same dependencies. So it is no harder for someone that only needs one of the packages to install the whole thing, and then use the bits they need.
And it's open source -- folks can contribute to the parts they care about, while ignoring the other parts.
So what does this mean for pyugrid and pysgrid?
We at ERD wrote most of the pyugrid code -- we'll finish a little clean up right now, but are not going to maintain it any further.
pysgrid was written mostly by @ayan-usgs, with extension and maintenance by a few other folks since then.
So it's up to @ayan-usgs and the others to decide what they want to do, but ERD will not be contributing directly to pysgrid any more.
I highly encourage users of pyugrid and pysgrid to come on over and try gridded -- it gives you lots of cool stuff, and more importantly, opens the door to even more. For the most part, you should be able to simply change your imports to:
from gridded import pyugrid
or
from gridded import pysgrid
and have the same functionality you have now. (though there is no guarantee, as we unify the APIs, things WILL change.
But if you check out gridded.Dataset, you'll get a whole lot more...
To be fair, gridded is currently a bit hacked together to support what we need to support -- the API could be cleaner, the code better structured, and it definitely needs better docs and more examples. Plus added functionality!
So come join us and make it a great tool for all of us.
NOTE: we put gridded in the NOAA-ORR-ERD organization, as that's where we put our code. But if it would help make it a more community project, we'd be happy to move it to another org.
@ayan-usgs @jay-hennen @ocefpaf @rsignell-usgs @kwilcox @jahennen @hetland @daf @RSully
The text was updated successfully, but these errors were encountered: