-
-
Notifications
You must be signed in to change notification settings - Fork 331
accelerating v2 -> v3 migration #3076
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'd add:
|
Is this not already covered in the existing migration guide? A wrapper class seems very useful, and might even expose some incompatibilities. You could also make a wrapper class and then raise deprecation warnings when it gets used. |
This was discussed at length in the run up to the 3.0 release. Ultimately, we choose to remove the 2.18.X code from the release. With that in mind, I'm curious what has changed that would have us reverse this? I'm not entirely opposed to it but I'd like to think through the process a bit.
This is a good idea. It will not be easy to make async-friendly but it will "work"
From the perspective of Xarray users, getting the 3.0 dtypes and codecs into a stable state is the highest priority at this point. |
There are a few v2 functionalities that still don't exist or work properly in v3 for full migration of our workflows (at least for us).
|
Just a comment from a user perspective, adding onto the previous comment. We delay(ed) the move to v3 not because of migration difficulties, but due to a few missing features (e.g. copying stores), |
Adding back some kind of least-recently-used cache would be very helpful too. (like LRUCache in v2) |
Just going to link this here for reference: |
@psobolewskiPhD - would you mind opening a separate issue to discuss performance regressions? We'd love to understand the issue here but we've seen the opposite result in many zarr3 applications so we'll need to dig in to be helpful. Anything you can provide in terms of a reproducer would be great. |
It's been several months since we released zarr-python 3 and there are still many active projects using zarr-python 2. For people deeply invested in the zarr-python 2 store API, migration to zarr-python 3 may not be easy, since the store API is very different. With this in mind, I think we should explore options for making migration from the zarr-python 2 APIs to the zarr-python 3 APIs easier.
A few ideas:
v2
namespace in zarr-python 3 that contains all the code from zarr-python 2.x. See this zulip post, and this PRMemoryStore
is a good target for this. This might be of interest to people who wrote a lot of zarr-python-v2-compatible stores that would be onerous to directly migrate (cc @cgohlke)Any other ideas?
The text was updated successfully, but these errors were encountered: