ENH: Migrate data to IPFS

[thewtex]

No description provided.

[dzenanz]

Is kicking out sha512s a WIP simplification, or a longer-term plan?

[thewtex]

Is kicking out sha512s a WIP simplification, or a longer-term plan?

Both

[thewtex]

This improves build reliability, addressing #395, but also simplifies the contributor experience and improves maintainability and sustainability.

Documentation updates were factored into a separate commit to facilitate review.

[tbirdso]

Not strictly necessary, but it would be helpful to have a comment on each function summarizing intended behavior and detailing input formats and example usage. I.e. # Usage: ExternalData_add_test(ReadAnImageData), etc.

[thewtex]

Yes, although we do not want to diverge from upstream ExternalData.cmake.

[tbirdso]

we do not want to diverge from upstream ExternalData.cmake

It doesn't seem like this constraint will be easy to enforce on a forked file here. Is there another way we could reference ExternalData.cmake from an existing ITK source dir or fetch it from an ITK hash with FetchContent at build time?

[dzenanz]

We could require a newer version of CMake which does have IPFS support in ExternalData. Matt, do you know which is the oldest version good enough for this?

[jcfr]

To clarify, the IPFS support has not yet been contributed to upstream CMake ¹

Waiting we integrate it upstream, an intermediate approach would be to maintain the modified ExternalData module into a project called for example cmake-IPFS-ExternalData (or just cmake-ExternalData) maintained in the @InsightSoftwareConsortium GitHub organization.

Structure would be similar to what we are doing for scikit-build/cmake-FindVcvars and scikit-build/cmake-FindFortran.

The proposal structure provide clear guideline for:

• integrating the custom module in projects
• versioning the module for easy integration

Footnotes

1. https://github.com/Kitware/CMake/blob/master/Modules/ExternalData.cmake ↩

[thewtex]

Yes, good idea. I will start a new dedicated repository for the module when integrating into the ITK repository.

Note that it intentionally has not been submitted to upstream CMake because of the current lack of availability of a C++ CID verification library.

[tbirdso]

Thank you for adding documentation @thewtex .

[jhlegarreta]

Thanks for all this hard work Matt 💯.

I only have one concern: why is the Documentation/Contribute/ContributeWithGit.rst file being removed?

It deals with contributing to the repository; and is not related to the data part (if any part does refer to the data, then cross-referencing Documentation/Contribute/UploadBinaryData.rst would suffice).

Last, I think we have tried keeping the line length under 79 characters for RST files. Maybe in the long run having a linter for this would make our life easier.

[thewtex]

I only have one concern: why is the Documentation/Contribute/ContributeWithGit.rst file being removed removed?

@jhlegarreta great catch! That should not have been removed.

Last, I think we have tried keeping the line length under 79 characters for RST files. Maybe in the long run having a linter for this would make our life easier.

Yes, I went through and wrapped.

[jhlegarreta]

Building the documentation is causing some probably justified warnings.