-
Notifications
You must be signed in to change notification settings - Fork 6
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
Introduce/update overwrite parameter for most tasks #499
Introduce/update overwrite parameter for most tasks #499
Conversation
Coverage reportThe coverage rate went from
Diff Coverage details (click to unfold)fractal_tasks_core/tasks/copy_ome_zarr.py
fractal_tasks_core/tasks/napari_workflows_wrapper.py
fractal_tasks_core/tasks/create_ome_zarr.py
fractal_tasks_core/tasks/illumination_correction.py
fractal_tasks_core/tasks/create_ome_zarr_multiplex.py
fractal_tasks_core/tasks/cellpose_segmentation.py
fractal_tasks_core/lib_write.py
fractal_tasks_core/lib_ROI_overlaps.py
fractal_tasks_core/tasks/maximum_intensity_projection.py
fractal_tasks_core/tasks/yokogawa_to_ome_zarr.py
fractal_tasks_core/lib_metadata_parsing.py
|
This reverts commit 5cc4da6.
This PR is essentially ready on my side, and any feedback is welcome. The PR is independent from the registration tasks introduced in #487, and the two branches have no conflict at the moment. I'd propose to merge this one first, and then address the overwrite-related features to the registration tasks somewhere else (either as part of #487 or as another PR about #498). One last (minor) point to fix in this PR is maybe the code organization. Right now I added a broad-scope
I think this code organization is not ideal. Some possible improvements:
|
@tcompa That's awesome! I'll try to review as soon as possible. But may be Friday afternoon or Monday next week given the current conference |
No problem. The two branches at the moment have no conflicts (see registration_task...491-introduceupdate-overwrite-parameter-to-most-tasks), and they are both at a quite advanced stage - thus I think that extra care in the merging order is not needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR looks great. I found one small issue in the illumination correction task and a few small docstring TBDs to be replaced.
Regarding the naming of lib_zarr: I agree, that's a bit too general. I'd be fine with lib_writing
or any better ideas you have :) Could be lib_zarr_writing?
Other than that, ready to merge I'd say. Great work @tcompa ! 👏🏻
I went with In the future we may want to review the structure of the core library, and introduce some more consistent module naming and/or folder organization. We may also export a bunch of |
Side comment: this task includes a few unreachable code paths which cannot be tested, we'll need to review everything once we support
Fixed, thanks! |
This is ready to merge, as soon as we agree on the |
Agreed on the build_pyramid overwrite, we can merge! :) |
Close #485
Close #492
Close #493
Close #494
Close #495
Close #496
Close #497
Close #458
Close #500
Checklist before merging
CHANGELOG.md
overwrite=False
, actually overwrite existing output. The first one is the one we are already testing, the second one should be somewhat easy (every time we run a task for the first time, we also re-run it right away withoverwrite=False
and catch the error).prepare_label_group
(mostly similar to the ones forwrite_table
)lib_zarr
, or move its functions to more appropriate modules.