No support for `python3.9` even though this is not EOL

[AyanSinhaMahapatra]

We recently encountered some issues when doing a pip install scancode-toolkit due to some silent changes in how click handles ProgressBar attributes, i.e. EnhancedProgressBar.is_hidden was renamed to EnhancedProgressBar.hidden. Our CI was also failing because of this as we test for latest versions of all dependencies on supported OS/python combinations.

See aboutcode-org/scancode-toolkit#4369 for more details on this.

We decided to use the new versions since we already had complex version constraints for click due to various regressions (like: #2832). We also test for all click versions we support to catch against regressions.

But this update does not work because starting click version 8.2.0, you are no longer supporting python3.9 with #2893

Note that because there was breaking changes and you've dropped a non-EOL python version simultaniously, we cannot use anymore latest versions of click going forward (or atleast untill python3.9 is EOL) since we plan to support using scancode-toolkit in all non-EOL python versions.

From https://palletsprojects.com/versions:
it supports all Python versions that are not within six months of end of life (EOL)

Seems like this change was introduced recently as click 8.1.8 supported python3.7 even though it was EOL for more than a year. While dropping support for EOL python versions is great and much welcomed, could you explain why you are dropping support for non-EOL versions since 6 months is a long time and as libraries we do need to support older python versions as they are still being used actively. IMHO being unable to use latest versions (with possible security updates) is worse than using non-EOL python versions.

Environment:

• Python version: 3.9
• Click version: 8.2.0 and above

[davidism]

Feature releases happen relatively infrequently, meaning bug fixes can happen against them for quite some time. Once a Python is EOL, it becomes much harder to support it locally and in CI, especially for contributors. We don't want to commit to supporting bug fixes on a Python version that will soon be unsupported, as we will likely need to support it long after it's unsupported as well.

Note that ProgressBar.is_hidden/hidden is not documented, and therefore was never part of the public API. You're welcome to use private APIs, but need to be aware of when you do so. This is not specific to Click, it's true of Python in general.

In order to support multiple package versions, you can use the same patterns used to support multiple Python versions. This isn't specific to Click, this is a general pattern in Python and libraries that want to support multiple versions that may have incompatible changes.

For example, in the linked PR, your subclass could add a is_hidden property to support the old version, with a comment to remove it when you decide to drop support for Python 3.9 or Click 8.1.

class CompatProgressBar(click.ProgressBar):
    # TODO Remove when dropping support for Python 3.9 or Click 8.1.
    @property
    def is_hidden(self) -> bool:
        return self.hidden

    @is_hidden.setter
    def is_hidden(self, value: bool) -> None:
        self.hidden = value

We're happy to help you find compatibility fixes like this. Please ask on the Discussions tab or in our Discord https://discord.gg/pallets.