Dependency Version/Deprecation Policy

[ericspod]

MONAI has an existing policy for deprecating components it defines here. For dependencies there isn't as clear a policy to follow in regards to which versions of Python, Numpy, Pytorch, etc. to support. It's important to support older environments as much as is practical so that users with frozen environments have the fewest issues with new versions of MONAI. There are a few considerations that vary by library which need to be composed into a clear policy:

• Python versions of have end-of-life dates and so we should support only those versions that haven't reached that date.
• Pytorch's releases have for a long time never been out of sync, that is there have been no bug fixes for old versions for a very long time, and so old versions immediately become out-of-support. This is an issue with known security vulnerabilities in older versions which won't be fixed, so Bump min torch to 1.13.1 to mitigate CVE-2022-45907 unsafe usage of eval #8296 has been proposed to remove old versions from the CICD system. A subsequent PR will remove more versions further as discussed here .
• Numpy has released version 2.x which introduced some incompatibilities with other dependencies, though MONAI itself should be compatible. This has created the situation where we have to specify that MONAI requires 1.x to prevent pip from installing incompatible combinations of libraries. At some point this will be fixed and the version restriction can be removed.
• Other dependencies may deprecate versions, or vulnerabilities discovered for them.

All this means we need to determine:

• How old are the versions of dependencies we want to support.
• How to decide when to remove support for certain dependency versions and by whom.
• How to respond to discovered vulnerabilities.
• How and when to re-analize the dependencies that we have to determine if version requirements are still suitable.
• Who may add or remove dependencies, even optional ones.
• Who may mark other repositories as archived or de-archive them (I'm thinking specifically of archiving GenerativeModels).

[jamesobutler]

This has created the situation where we have to specify that MONAI requires 1.x to prevent pip from installing incompatible combinations of libraries.

I would suggest the creation of a new GitHub issue documenting which monai dependency does not have support for numpy 2 which is preventing the numpy < 2 from being removed. Most major python packages have been updated to be compatible with both Numpy 1 and 2 by following https://numpy.org/doc/stable/dev/depending_on_numpy.html#numpy-2-0-specific-advice. The numpy GitHub repository has a pinned issue about numpy 2 ecosystem compatibility detailing which versions of major python packages added numpy 2 support.

[jamesobutler]

How old are the versions of dependencies we want to support.

As it relates to versions of dependencies to support as well as versions of Python to support, my recommendation would be to consider adopting SPEC0. This is because monai is ultimately dependent on the core base of numpy.

[ericspod]

As it relates to versions of dependencies to support as well as versions of Python to support, my recommendation would be to consider adopting SPEC0. This is because monai is ultimately dependent on the core base of numpy.

Thanks for the info, these are sensible timeframes for dependency support. From a newly created Python environment under Ubuntu 24.04 and all of MONAI's stated dependencies installed, I have the following for dependencies uploaded to PyPI before 2023:

2019-02-12T07:22:28  PythonWebHDFS                  0.2.3
2019-07-10T20:11:45  orderedmultidict               1.0.1
2019-09-20T02:06:20  PySocks                        1.7.1
2019-12-10T01:50:33  astor                          0.8.1
2020-11-01T01:40:20  toml                           0.10.2
2021-08-25T22:10:31  lpips                          0.1.4
2021-09-27T21:31:14  furl                           2.1.3
2021-12-10T21:09:37  typeguard                      2.13.3
2022-01-24T01:14:49  mccabe                         0.7.0
2022-02-10T18:01:07  pathlib2                       2.3.7.post1
2022-04-16T11:03:43  graphql-relay                  3.2.0
2022-07-20T10:28:34  rsa                            4.9
2022-08-14T12:40:09  mdurl                          0.1.2
2022-10-06T17:21:44  tabulate                       0.9.0
2022-10-25T02:36:20  colorama                       0.4.6

(This was created with pip list|tail -n+3|while read i;do ar=($i);echo ${ar[0]} ${ar[1]} $(curl -s https://pypi.org/pypi/${ar[0]}/json|jq -r ".releases[\"${ar[1]}\"][0].upload_time");done|awk '{printf "%-20s %-30s %s\n",$3,$1,$2 }' |sort|tee release_dates.txt.)

There isn't a large number of these but many which are the latest release dependencies of other things. I see that typeguard and lpips are specificly restricted in our requirements files, we should revisit these and see if they can be upgraded now.

[aylward]

I think we should track dependencies based on PyTorch (which is a bit of a weak standard since they don't have an LTS/enterprise strategy).

Currently we're still supporting (just bumped to) PyTorch 1.13.1, and it isn't fully compatible with numpy 2.0.

I suggest that since our next release is going to be a major release (that is what I recall, sorry if I'm mistaken), then we should use that opportunity to bump both PyTorch and Numpy to 2.x. In particular, perhaps target PyTorch version 2.2 since it is compatible with any Numpy 2.x. I haven't fully thought this thru and y'all have more expertise than me in this, but this is my current thinking...

[jamesobutler]

In particular, perhaps target PyTorch version 2.2 since it is compatible with any Numpy 2.x.

From numpy/numpy#26191, it actually appears that PyTorch 2.3.0 was the first version built with Numpy 2 to support runtime with Numpy 1 or 2. MONAI wouldn’t have to require Numpy 2 as PyTorch would still work with some of the last few Numpy 1.x releases. However the PyTorch Windows binaries were messed up and didn’t actually build with Numpy 2 until PyTorch 2.4.1.

[ericspod]

In particular, perhaps target PyTorch version 2.2 since it is compatible with any Numpy 2.x.

From numpy/numpy#26191, it actually appears that PyTorch 2.3.0 was the first version built with Numpy 2 to support runtime with Numpy 1 or 2. MONAI wouldn’t have to require Numpy 2 as PyTorch would still work with some of the last few Numpy 1.x releases. However the PyTorch Windows binaries were messed up and didn’t actually build with Numpy 2 until PyTorch 2.4.1.

With PyTorch 2.6 released now, if we wanted to support only the most recent two versions we can set the minimum to be 2.4.1 at some point. I think this is feasible since PyTorch doesn't do LTS releases nor fixes old releases as previously discussed.

[aylward]

My only concern is the statement that we're supporting only the two most recent pyorch releases. They are releasing new versions crazy fast. Pyorch 2.4 was released only 7 months ago (July 2024).

Open question...is asking folks to update pyorch every 6-7 months too much, even when working on HEAD? Perhaps this is fine, and when there are critical fixes such as Windows support being fixed then more rapid updates may be needed, but perhaps our default should be a longer timeframe? Just asking, not necessarily suggesting...

[ericspod]

Open question...is asking folks to update pyorch every 6-7 months too much, even when working on HEAD? Perhaps this is fine, and when there are critical fixes such as Windows support being fixed then more rapid updates may be needed, but perhaps our default should be a longer timeframe? Just asking, not necessarily suggesting...

We can say this is what we test with but older versions likely will work, but I'm with you on not wanting to be onerous. Users can configure their own environments to use older versions, but what requirements we state will be those used by pip for installation so they have to be accurate. If we say that we support versions of PyTorch and Numpy which don't get along that could be a problem.

[ericspod]

Another concern is when issues such as this one from dependabot come up, do we address them immediately or decide what is a worthwhile risk?

[jamesobutler]

Yes it would be a good idea to have dependabot enabled to autoupdate dependencies to address vulnerabilities in the stack. So in that case updating transformers usage to >=4.48.0 to address GHSA-wrfc-pvp9-mr9g. Addressing High and Critical reports would be a reasonable goal.

MONAI/setup.cfg

Line 70 in af9e8f9

transformers>=4.36.0, <4.41.0; python_version <= '3.10'

See Project-MONAI/MONAILabel#1749 where there was original discussion about that project turning on dependabot which it did. Turning it on then resulted in automatic PR creation of Project-MONAI/MONAILabel#1754 to resolve GHSA-9wx4-h78v-vm56.