ENH: Allow newer version of dependencies

[jamesobutler]

Pinning basic packages such as "requests" to a specific patch level release such "2.31.0" is too strict. New releases and especially new patch releases allow to use latest security updates of various packages.

[jamesobutler]

cc: @diazandr3s I have run into various python package version conflicts (due to too strict pinning) when building MonaiLabel Slicer extension into one of my Slicer custom applications. This is the motivation for this change.

[jamesobutler]

@tangy5 Would you be able to provide review for this work?

[SachidanandAlle]

Changing to >= is not recommended for dependency packages.

For example tonight it might work one user and tomorrow the same PIP version of monailabel can become unstable for another user. May not even get installed or as issues as one of the dependent versions get upgraded. also we can't track any changes in the license type between old and new dependent versions.

If you are looking for updating any dependent packages, please update them to the next best version.
And each such update needs to make sure all the test cases pass and all the apps (radiology, pathology etc..) works well for both inference, training etc over min monai bundles/models.

Also please get it tested/verified via 3D slicer or ohif viewer for certain e2e usecase.

[SachidanandAlle]

Also Note..

due to old setup.cfg way of building the pip package, the dependencies for the monailabel pip package is actually pulled from https://github.com/Project-MONAI/MONAILabel/blob/main/setup.cfg#L37

requirements.txt is for development env or for setting up docker dependencies.

[jamesobutler]

Thanks @SachidanandAlle for pointing to https://github.com/Project-MONAI/MONAILabel/blob/main/setup.cfg#L37.

For example tonight it might work one user and tomorrow the same PIP version of monailabel can become unstable for another user. May not even get installed or as issues as one of the dependent versions get upgraded. also we can't track any changes in the license type between old and new dependent versions.

Major python packages with dependencies do not subscribe to this technique of hard pinning to a specific version. Upper bounds for known breaking behavior or exceptions for known failures are added, but not the strict behavior of pinning to a specific version. For a developer doing research on tasks, they can definitely subscribe to a pip freeze type development to use the exact versions of all dependencies, but this should not be managed as such at the python package level.

[SachidanandAlle]

Today, there are 2 types of distributions for monailabel.

1. Docker
2. PIP Package

When we stop 2nd option then I do recommend the >= option for dependent packages. Because docker has the state that is verified/tested and remains constant.

I do understand that major python packages do not subscribe this hard pinning.
But for monailabel we want to guarantee what worked yesterday (or on the day of release tag), will work today. We are not expecting monailabel to support getting along with other packages in the same venv.

[jamesobutler]

But for monailabel we want to guarantee what worked yesterday (or on the day of release tag), will work today.

For clarity why is it today that monai core (specified as a dependency of monailabel) does not have a hardened pin?

MONAILabel/setup.cfg

Line 38 in b85d6b1

monai[nibabel, skimage, pillow, tensorboard, gdown, ignite, torchvision, itk, tqdm, lmdb, psutil, openslide, fire, mlflow]>=1.3.1

monai core itself does not specify a hard pin for packages such as numpy, torch, etc per https://github.com/Project-MONAI/MONAI/blob/1.3.2/setup.cfg#L43-L45. Additionally scipy and scikit-learn have no hard pin, but urllib3 does. There appears to be an inconsistency in approach here where it should have no bounds specified or at least minimum bounds based on known compatibility purposes.

MONAILabel/setup.cfg

Lines 69 to 71 in b85d6b1

	urllib3==2.2.1
	scikit-learn
	scipy

[SachidanandAlle]

very good question.
there is a tiny difference between monai and monai label. library vs final solution.

monai expects someone to use it as a dependent package to create some product/solution.
monailabel expects itself to be the end product/solution.

and on regarding scikit-learn and scipy not having version, i would suggest team to get it fixed. if they are getting pulled from other dependent chain, then just remove it as direct dependency. i will consider it as a bug to be fixed.

i hope that answers your question.

[jamesobutler]

I think fundamentally the difference is that I've been considering monailabel to be a python library used in my end-application of choice and that monailabel itself is not a hardened product.

@lassoan Do you have thoughts you can provide here about the hard pinning of dependencies which can collide with 3D Slicer dependencies leading to unnecessary install/uninstall events of packages?

[jamesobutler]

and on regarding scikit-learn and scipy not having version, i would suggest team to get it fixed. if they are getting pulled from other dependent chain, then just remove it as direct dependency. i will consider it as a bug to be fixed.

One thing to consider in the case of scipy is that there is no single version of scipy that is compatible with the current specification where monailabel specifies it works for python >=3.8. There is not a single version of scipy to support all stables releases of Python >=3.8 which include 3.8.x, 3.9.x, 3.10.x, 3.11.x, 3.12.x and 3.13.x. You would have to at minimum specify a hardened version of scipy specific to various python versions.

MONAILabel/setup.cfg

Line 30 in b85d6b1

python_requires = >= 3.8

This is because scipy dropped support for Python 3.8 starting with v1.11.0. The older scipy v1.10.x only has whl files for Python 3.8-3.11 (https://pypi.org/project/scipy/1.10.1/#files) and then scipy v1.14.0 dropped support for Python 3.9.

[lassoan]

I have the exact same thoughts as @jamesobutler. Only applications are aware of all the end-user goals and all the required tools, libraries, and environment, so only applications can define exact library versions. Libraries should be as permissive as possible with their requirements to make it feasible to build applications.

I understand that It requires extra effort from library developers to be compatible with a range of versions of many dependent libraries, but this is necessary, otherwise developers would not be able to embed/customize/extend the software for their application.

[SachidanandAlle]

Lets merge this for now.
Lets track any issues related to installation from customers. in that case we can revert this PR if needed.