kombu
kombu copied to clipboard
celery
Issues with pinned typing-extensions
typing-extensions has released 4.13.0 But it looks like kombu is pinning it to 4.12.2 - https://pyoven.org/package/kombu/5.5.1
typing-extensions did drop support for 3.7 in a minor release 2 years ago, but 4.13.0 retains support for Python 3.8 so it should be safe to upgrade or at least include in a flexible version range. I assume this is the same problem as #2272 where kombu's pinned version is now preventing other projects from keeping their own dependencies up-to-date.
I can see this typing-extensions==4.12.2; python_version < "3.10" that means python version above python 3.10 would be able to use other versions?
typing-extensions is a polyfill designed to backport new language features to old versions of Python. Presumably the requirement is there because kombu is using a feature that was only introduced in Python 3.10, hence the need to require the library for 3.8 and 3.9.
Edit: sorry, to answer more directly, you are correct that anyone running Python >= 3.10 can use other versions because kombu is not making any requirements at all. The projects I am working with are mostly 3.11 and 3.12 based, so this pin is not preventing us from upgrading (although the tzdata pin from #2272 is), but I guess users still running Python 3.8 or 3.9 will be blocked by this.
Before https://github.com/celery/kombu/commit/1df567a5e813b9030b858b454e51eb70ea928e6a it was completely unconstrained. IMO that was indeed wrong: it should have read >=4 because there are two things that kombu expect from that library which are only reliably available from 4.0 (maybe a bit earlier): TypeGuard and ParamSpec.
Would be great if kombu only constrained it to what it really needs:
typing-extensions>=4; python_version<"3.10"
Pinning exact versions especially for libraries (rather than applications) doesn't work with Python's dependency management. It's a practice that comes from Javascript, which has an entirely different system. See https://iscinumpy.dev/post/bound-version-constraints/.
Looks like there is a similar issue with tzdata too - tzdata is currently pinned and so causing conflicts with other packages
Using tzdata>2024 should likely be sufficient and does not need to be pinned to exactly 2025.2 ... which will be changing every month
I think this commit solve this https://github.com/celery/kombu/commit/f2240005f21d842d5fd81d05f5f4ab41d754d44e