Skip to content
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

[WIP] Fix relative references when store not in cwd #256

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

rly
Copy link
Contributor

@rly rly commented Jan 8, 2025

Motivation

Fix #255. Slight rework of how references are handled.

Currently, the "source" of links and references are relative to the directory that contains the currently open Zarr store.

Internal Zarr links and references use the name of the Zarr store as the "source". For example, if file1.zarr contains an internal link, that link looks like:

{
    "name": "foo_link",
    "path": "/buckets/bucket1/foo_holder/foo1",
    "source": "file1.zarr"
}

External links: If file0.zarr and file1.zarr are in the same directory, and file1.zarr has an external link to a group in file0.zarr, that link looks like:

{
    "name": "foo_link",
    "path": "/buckets/bucket1/foo_holder/foo1",
    "source": "file0.zarr"
}

When reading file1.zarr from elsewhere, e.g., ZarrIO("a/b/c/file1.zarr", mode="r"), we need to make sure that the relative paths are resolved correctly from a/b/c. Approach 1: Fix this.

An alternative approach, which I believe was the original implementation, is that instead of writing paths relative to the directory that contain the currently open Zarr store, write paths relative to the currently open Zarr store. So internal links and references would have the source: "." and the above external link example would have the source: "../file0.zarr". Approach 2: Return to this pre-0.10.0 way of storing "source" in links and references.

I propose we take approach 2, because otherwise links in files written under the original implementation would not be readable - I tested this and indeed files with links written in 0.8.0 cannot be read in 0.10.0 - and approach 2 does not suffer any disadvantages in my eyes.

@mavaylon1 Let me know what you think.

TODO

  • Update tests once we settle on an approach

Checklist

  • Did you update CHANGELOG.md with your changes?
  • Does the PR clearly describe the problem and the solution?
  • Have you reviewed our Contributing Guide?
  • Does the PR use "Fix #XXX" notation to tell GitHub to close the relevant issue numbered XXX when the PR is merged?

@rly rly marked this pull request as draft January 8, 2025 21:48
@rly rly requested a review from mavaylon1 January 8, 2025 22:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]:
1 participant