Migrate to pyproject.toml and unpin Zarr

[LOCEANlloydizard]

No description provided.

[leewujung]

@LOCEANlloydizard : I am not sure how good the test coverage is, but I'll try to spin up a new env using this and see how it goes!

[leewujung]

I ended up spending the time I had updating the service to deploy the prefect worker... so I haven't tested this update. Could you try to see if you could read a zarr v3 Sv file?
something like below in viz_echogram_track.py in echodataflow

ds_MVBS = xr.open_zarr(path_MVBS / "latest_MVBS.zarr")
egram = ds_MVBS.eshader.echogram(
    channel=[
        "WBT 400141-15 ES18_ES",
        "WBT 400143-15 ES38B_ES",
        "WBT 400142-15 ES70-7C_ES",
        "WBT 400140-15 ES120-7C_ES",
        "WBT 400145-15 ES200-7C_ES",
    ],
    vmin=-70,
    vmax=-36,
    cmap="viridis",
    opts=opts.Image(
        width=1000, height=400,
        tools=["pan", "box_zoom", "wheel_zoom", "reset"],
    )
)

[LOCEANlloydizard]

Hi @leewujung, so I tested all the notebooks with the updated pyproject.toml dependency stack with:

• echopype 0.11.1
• xarray 2026.4.0
• zarr 3.2.1
• numpy 2.5.0

I checked:

• all notebooks run successfully
• read concatenated_MVBS.nc, converted it to Zarr v3, reopened it with xr.open_zarr(), and successfully rendered the echogram with Echoshader
• downloaded the example raw file from Getting Started, saved the ED as Zarr, reopened it with ep.open_converted(), computed Sv/MVBS, saved the MVBS dataset as Zarr v3, reopened it with xr.open_zarr(), and successfully rendered the echogram from the Zarr-backed dataset

I did see a few Zarr v3 warnings (the "classic" deprecated compressors and string dtypes) but it passed! Hopefully this works smoothly in Echodataflow as well! Let me know if not!

[leewujung]

Oh this is great! I will hopefully be able to test this today! Thanks!

[leewujung]

Confirmed that the echogram display works in the cloud workflow, and the new packaging works smoothly when creating a new environment. Thanks @LOCEANlloydizard !!

The only thing I wonder is if we should have the "all" option for the optional dependencies. I opted for not having that echodataflow and just have separate options that one needs to include during installation, because I feel it may be hard to always remember to update both the dev (or test) and all. Thoughts?

[LOCEANlloydizard]

Oh awesome @leewujung!! yes I agree we can just drop "all"! I just removed it 👍 feel free to merge if everything looks good on your end! Cheers!

[leewujung]

Ah one small thing - could you change to using ruff for linting? Seems a better option since we use it for another package (I forgot which!) now due to flake8 issues. Thanks!

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[LOCEANlloydizard]

oh yes ok, you're right! i think it was echopop that we changed to using ruff? yes we should probably do the same across the other repos as well, i'll open an issue for echopype too so we don't forget!

(EDIT: we did it already for echopype as well! so opened an issue here just to track that somwhere..)

I've updated this PR to use Ruff instead of flake8. While doing that, I also:

• enabled Ruff linting for both the Python code and notebooks,
• cleaned up the notebooks (unused imports, import ordering, etc.),
• excluded notebooks from ruff format so they're linted but not automatically reformatted.

Let me know what you think!