Adding copy_store convenience method for Group

[melonora]

[Description of PR]
This PR adds a convenience method for copying the store of a Group to a destination store.

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/user-guide/*.md
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

@d-v-b

[codecov]

Codecov Report

❌ Patch coverage is 88.88889% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.97%. Comparing base (884a8c9) to head (f3e4f87).

Files with missing lines	Patch %	Lines
src/zarr/core/group.py	88.88%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3612      +/-   ##
==========================================
+ Coverage   60.90%   60.97%   +0.07%     
==========================================
  Files          86       86              
  Lines       10174    10199      +25     
==========================================
+ Hits         6196     6219      +23     
- Misses       3978     3980       +2     

Files with missing lines	Coverage Δ
src/zarr/testing/strategies.py	97.83% <ø> (ø)
src/zarr/core/group.py	70.85% <88.88%> (+0.57%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[melonora]

@d-v-b I know right now this won't work when zarr v2 is used. I can add that functionality as well or we say the convenience function is not supported for zarr v2.

[melonora]

added zarr v2 support. If in general the code is approved, I will add documentation.

[d-v-b]

why do we need this here? IMO it's simpler if copying is just copying. If people want to add consolidated metadata, they should do that after copying.

[melonora]

adjusted it. It now consolidates if the source store was consolidated, but this does not require an argument. One more thing, I only take into account when consolidation happened at the root level. It could be (although the user should not do this) that consolidation happened at the subgroup level. This could be accounted for by checking if member. metadata.consolidated_metadata when looping through members. WDYT should I add this?

[d-v-b]

I would copy the original group and its children exactly, including their consolidated metadata.

[melonora]

What would be the purpose of copying over stale consolidated metadata?

[d-v-b]

it keeps the scope of this function simple -- it just copies the original group exactly. If this tool produces a different group, then it's not really copying.

[melonora]

regarding the from_store method, I would open a separate PR for this.

[joshmoore]

Consolidated metadata is already in the group metadata document for zarr v3 if "kind" is set to "inline".

👍 but doing something other (more or less) than just copying would require interpreting that which is too far IMO.

[d-v-b]

FYI @joshmoore the method under discussion here is a method on the Group class, not on stores. maybe this is a point of confusion.

[d-v-b]

IMO the only consolidated metadata-related parameter we need is whether iterating over the child groups uses their consolidated metadata (if present). See the relevant kwarg in the signature of members.

[melonora]

I added both, only thing remaining is probably adding consolidated_metadata in the async group call.

[melonora]

@d-v-b @joshmoore I think I have now addressed all comments and I also added documentation, so I think this would be ready for a final round of review. @d-v-b thanks for your patience.

[melonora]

@d-v-b @joshmoore , just bumping in case you have some time to see whether you approve the current state:)

[d-v-b]

we should add a test that checks the signature of this function against the signature of the async version. otherwise, they have a tendency to drift. Here's an example of such a test:

zarr-python/tests/test_api/test_synchronous.py

Lines 26 to 41 in ee0e69a

	def test_docstrings_match(callable_name: str) -> None:
	"""
	Tests that the docstrings for the sync and async define identical parameters.
	"""
	callable_a = getattr(synchronous, callable_name)
	callable_b = getattr(asynchronous, callable_name)
	if callable_a.__doc__ is None:
	assert callable_b.__doc__ is None
	else:
	params_a = NumpyDocString(callable_a.__doc__)["Parameters"]
	params_b = NumpyDocString(callable_b.__doc__)["Parameters"]
	mismatch = []
	for idx, (a, b) in enumerate(zip(params_a, params_b, strict=False)):
	if a != b:
	mismatch.append((idx, (a, b)))
	assert mismatch == []

[melonora]

so I did not do the actual docstrings itself, but I did write a test for all methods for classes and their async counterparts. I think this is generalizable to other classes as well, though currently only Group and AsyncGroup are tested. With this, already some mismatches are detected which for now are skipped but could be addressed in a follow up PR. Doing so would require deprecating some parameters. If you agree I can create an issue for it.

[melonora]

Please see test_class_method_parameters_match

[melonora]

@d-v-b When the last test passes and if you are happy with the code changes I think this is good to go. Thanks for reviewing!