-
Notifications
You must be signed in to change notification settings - Fork 9
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
Capabilities interface #113
Capabilities interface #113
Conversation
See checks for 79f117c marked "pull_request", rather than "pull_request_target". |
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.
Zarr V3 stuff looks good other than some nits/optional suggestions.
Still need to take a closer look at the capabilities stuff. From a quick look at the implementation and tests, I think it looks fine, though maybe the implementation is more verbose than I was expecting.
Optional, but I do think this would be easier to review if it was split into 2 (or maybe 3) PRs. One for Zarr V3 support + tests, one for capabilities, and maybe an extra one for some of the other stuff (version, readme updates, clean up).
FWIW, I opened it when I thought it would be smaller and get in faster. Happy to split. |
Co-authored-by: Andy Sweet <[email protected]>
Revert minor version bump.
This reverts commit b3c90dd.
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.
After a first pass, this mostly looks fine. I focused on the Python class definitions, rather than the binding implementations. The only one that looked like slightly strange/unexpected is TriggerCapabilities
(see the line comment for more details).
src/camera.rs
Outdated
#[pyclass] | ||
#[derive(Debug, Clone, Serialize, Deserialize)] | ||
pub struct CameraCapabilities { | ||
#[pyo3(get, set)] |
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.
Should most (maybe all?) of the Python attributes/properties in this PR be read-only (i.e. pyo3(get)
)?
Or do we need the set
internally?
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.
We don't actually need set
internally. Will fix.
b32fde5
to
1c102ee
Compare
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.
Looks good to me now. I have a nit to pick around the ChunkingShardingCapabilities
class name, but I'll leave that up to you.
Given the amount of new public API here, I think it could be worth @nclack taking a pass over this too.
python/acquire/acquire.pyi
Outdated
height: int | ||
planes: int | ||
class StorageCapabilities: | ||
chunk_dims_px: ChunkingShardingCapabilities |
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.
Nit: I don't love the name of the type here because it's long and includes two needs (that are the same right now, but might diverge in the future?). Is it worth using the same underlying private definition, but defining separately named classes for ChunkingCapabilities
and ShardingCapabilities
?
Similar comment for ChunkingShardingDims
.
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.
Agreed. I like the idea of exposing ChunkingCapabilities
and ShardingCapabilities
even though they derive from the same private type.
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.
ChunkingShardingCapabilities
should be changed but otherwise looks good. I'm having a little trouble running tests locally but it's probably something I'm doing wrong.
@@ -4,6 +4,7 @@ imgui.ini | |||
Testing | |||
*.zarr | |||
*.tif | |||
*.bin |
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.
where's the bin coming from?
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.
Writing out a raw file in one of the tests.
python/acquire/acquire.pyi
Outdated
height: int | ||
planes: int | ||
class StorageCapabilities: | ||
chunk_dims_px: ChunkingShardingCapabilities |
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.
Agreed. I like the idea of exposing ChunkingCapabilities
and ShardingCapabilities
even though they derive from the same private type.
…dingCapabilities. Split ChunkingShardingDims into ChunkDims and ShardDims.
Note: Storage metadata is unqueryable unless you start the runtime (issue here). In the test
test_storage_capabilities
, it was necessary to start the runtime for the test to pass, but that's really pretty terrible and I wouldn't choose to do that.