Move ngff transformations to separate repo?
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 394
- Forks
- 95
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 7
Description
Problem description
Hi all,
The problem I am seeing is not something acute at present, but may be become so in the future. The ngff-transformations in this repository are (save for a few incongruencies) a quite complete implementation of the pending RFC5 spec for transformations in the ngff standard. However, it would be impossible to import the transformations in packages that are dependencies of spatialdata.
A good example is the multiscale-spatial-image library, which may depend on ngff-zarr in the future (see this and this issue). That, in turn, would prevent ngff-zarr from importing spatialdata to use the ngff transformations therein as it would create a circular import.
Possible solution
The implementation of the ngff-transforms here is super neat and it would be nice to easily use it elsewhere, not only in the scope of spatialdata. Moving the code to a different repo would
- make spatialdata easier to maintain
- Give spatialdata outsiders an incentive to contribute if ngff transformations were usable by themselves
- Reduce maintenance burden to spatialdata devs
Alternatives
Well..anything in here is BSD-3 licensed so of course code can just be copied, but I feel that doing so would fall short of proper acknowledgement of the work that already went into the transformations in their current state.
Looking forward to hearing your thoughts on the matter!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the ngff-transformations implementation in spatialdata and the dependency paths involving multiscale-spatial-image and ngff-zarr. Check the RFC5 alignment and the referenced multiscale-spatial-image issues. Done means reaching an agreed decision and actionable plan for extracting the transformations without creating circular imports.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100