Labelings / Labeling

BSD 2-Clause "Simplified" License
4 stars 2 forks source link

Tifffile import conflicts with minimum python version #12

Closed gselzer closed 2 years ago

gselzer commented 2 years ago

setup.py requires tifffile=2021.4.8. This version `requires python 3.8 or newer. This project supposedly supports Python >=3.6, making a conflict.

Why are we pinning a particular tifffile version? Is it needed? Preferrably, we'd make this requirement as open as possible.

tomburke-rse commented 2 years ago

The conflict is a fair point, which I will fix asap. About the fixed version number: I try to always used fixed versions because I cannot guarantee ist always working with any future version, but I can guarantee it working with this specific version. I'd rather update the version from time to time than users having problems with dependency versions that I don't know of.

tomburke-rse commented 2 years ago

I upped the python version to 3.8 now, so this is fixed as is. If you have good arguments for always taking the newest versions, I'm open to change my mind.

gselzer commented 2 years ago

I think the argument for pinning vs. not pinning is well described here. Even projects that are arguably not reusable, e.g. napari, have minimal bounding.

In this case, we have a project that other libraries (namely pyimagej) would like to use. By pinning the version, we are making conflicts rather likely. Specifically, pyimagej currently supports Python 3.6+ (although I am currently trying to bump that minimum requirement to 3.7); the Python bump to 3.8 will make it impossible for us to use this project in pyimagej.

Furthermore, any other package that uses e.g. Tifffile will most likely result in conflicts upstream if we pin the version.

Supporting a minimum requirement is probably all you need to ensure reproducibility. You can also specify a major version, I think, if you want to defend against API changes.

gselzer commented 2 years ago

I'll also note that pinned versions don't help with build failures like this.

I'm not quite sure why pip seems unable to find the version you pinned, but it could likely work around this issue if we had a minimum requirement instead of a pinned version.

imagejan commented 2 years ago

I'm not quite sure why pip seems unable to find the version you pinned

My guess: because when building on Python 3.6, pip only lists versions that have the classifier Python :: 3.6?

gselzer commented 2 years ago

I'm not quite sure why pip seems unable to find the version you pinned

My guess: because when building on Python 3.6, pip only lists versions that have the classifier Python :: 3.6?

Yeah, probably. @tomburke-rse are we able to build this project with any of the versions discovered by pip (e.g. 2020.9.3)?

tomburke-rse commented 2 years ago

Thanks for the dependency restructure, it works and builds. I already did a release with it too.

gselzer commented 2 years ago

Wonderful, thanks again @tomburke-rse

gselzer commented 2 years ago

@tomburke-rse it looks like the feedstock is broken, as the dependencies were not updated in the recipe.