zhengruifeng commented on PR #52633: URL: https://github.com/apache/spark/pull/52633#issuecomment-3409032603
> @zhengruifeng, I have a silly question about Python deps management - I see that many Python deps are declared without a version, or with a range version(half-bounded, e.g. `foo>=1.0` or `bar<2.0`). Silently upgrading 3rd libs may introduce breaking changes (especially for major version bumping)/bugs. > > This means that if we do not specify the dependency version, or only specify the lower bound of the dependency version, PySpark may not work once a new major version of the dependency is released. This becomes a problem if users want to use older Spark versions (in practice, EOLed versions of Spark are used widely and upgrading is not timely). > > I wonder if Spark can pin all Python deps in a fixed version(or at least a bounded range version, e.g. `foo>=1.0,<=2.3`), this clearly shows the versions of Spark that have been fully tested. @pan3793 the reason to use lower bounds `foo>=1.0` in most places is to eagerly testing spark against latest packages (need to trigger the refresh of cached images), when spark get broken with new versions we set the upper bound (e.g. https://github.com/apache/spark/commit/22d2eb33f01ddff30e4f37fc529912372b35019b) and restore it once the issue get resolved (e.g. https://github.com/apache/spark/commit/47574ba833af370bc8527b352f846d4e3a645d77) currently, most workflows are testing against latests version; and we have two workflow against the minimum versions in which the versions of key packages (numpy/pyarrow/pandas) are pinned - https://github.com/apache/spark/actions/workflows/build_python_minimum.yml - https://github.com/apache/spark/actions/workflows/build_python_ps_minimum.yml But I personally think maybe we should use a fixed version `foo=1.2.3` or `foo>=1.0,<=2.3` in the officially released images @dongjoon-hyun @HyukjinKwon -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
