Issues with pinned typing-extensions

[AbdealiLoKo]

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

[auvipy]

may be that is due to retaining python 3.8 support?

[alisonatwork]

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.

[auvipy]

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?

[alisonatwork]

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.

[mrcljx]

Before 1df567a 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"

[jamesmyatt]

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/.

[AbdealiLoKo]

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

[jamesmyatt]

#2274 is the issue for tzdata

[auvipy]

I think this commit solve this f224000