Add NDTiff storage to the build automation

[henrypinkard]

Much like the java dependencies trigger updates to pycromanager version, the updating the version of NDTiff should automatically trigger a new version of pycro-manager on pypi. This likely requires expansion of the github action in NDTiffStorage and a new script in pycromanager that updates requirements.txt and setup.py. Most of this can be copied from the actions for the Java deps, I think

Linking a specific version of ndtiff to one of pycromanager is probably a good idea for reproducibility anyway

[ieivanov]

We list ndtiff>=1.8.0 as a requirement, so pipy will always install the latest version of ndtiff. Should we instead pin the ndtiff version? I think the current way of managing the ndtiff version works until there is a breaking change in the ndtiff API, at which point the developer would have to manually update the requirements within pycromanager.

Managing python packages seems to be easier than managing the Java dependencies because of the imposed link between the package versions and the dependency version in java.

[henrypinkard]

Yeah I think you're right, it works currently, but to me pinning seems better in general, because then it is always guaranteed that pycromanager a.b.c comes with ndtiff x.y.z. So if there's a problem with a Dataset, knowing the pycromanager version is sufficient to trace the problem.

I think you can similarly specify minimum versions in maven, so managing versions is essentially the same in Java or python. You can also tell maven to grab the latest version of a dependency, but as @marktsuchida has taught me, this is generally a bad idea for reproducibiliy

[ieivanov]

It does make sense, though as far as I know that's not the standard practice in the python community. I'm looking at the napari dependencies, for example: https://github.com/napari/napari/blob/main/setup.cfg

[henrypinkard]

I think the difference there may be that most of those are 3rd party dependencies. In that case, you want to be permissive on the range, because other things are installed that may also depend on different versions of those dependencies, and you want to let pip/conda have maximum flexibility in finding one that works for them all.

I we could probably just follow that convention and stick to pinning only a minimum version. I guess its possible to imagine a situation where you need a newer NDTiff, but don't want to upgrade pycro-manager because of API changes that need to be synced with MM

[ieivanov]

Ah, yes, that makes sense. OK, I agree!