Closed gselzer closed 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.
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.
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.
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.
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
?
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 classifierPython :: 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
)?
Thanks for the dependency restructure, it works and builds. I already did a release with it too.
Wonderful, thanks again @tomburke-rse
@tomburke-rse it looks like the feedstock is broken, as the dependencies were not updated in the recipe.
setup.py
requirestifffile=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.