Feature request: undeprecate __version__

[hmaarrfk]

I'm not sure why it took me so long to notice this in our warnings but I've been going through them now and noticed that __version__ was being deprecated.

#2598

I would like to make the case that while "this was an old pattern" it is very "simple", and it is a really good way to build in compatibility between between different versions of a package.

Personally, I still get bugs where:

• I am in the wrong directory, and thus i'm importing from a local folder with the same name as my module.
• "fighting" between different environment management tools leads to the "metadata" being out of sync.

Please consider undeprecating it.

Thank you!

[davidism]

Sorry, we don't plan to undeprecate this. As explained in the issue, changelog, and deprecation message, you should feature detection or the standard importlib.metadata.version if you do need to handle different versions.

You'll need to resolve those issues with your environment management on your own, they're not a reason for us to keep doing this. I can suggest using uv, pdm, or hatch, along with perhaps direnv or simimlar to automatically activate envs.

[hmaarrfk]

that is unfortunate (for me).

However, thanks for the response.

[kdeldycke]

@hmaarrfk I still support __version__ in Click Extra, my wrapper around Click: https://kdeldycke.github.io/click-extra/version.html#defaults

[hmaarrfk]

thanks I'll have to look at click extra.

[dwreeves]

__version__ saves a few milliseconds over import importlib.metadata; importlib.metadata.version("click") in rich-click. We spent a bit of time in our most recent minor version making command execution runtimes be as lightweight as reasonably possible, and one of the two big optimizations was moving off importlib and just checking click.__version__ (the other was lazy-loading things that were only used for printing the help text).

Moving to feature detection is difficult given the subtleties of the incompatibilities across versions, so for click 8.2+ we just need to eat the few additional milliseconds.

Doesn't seem like petitioning to keep it will work, just putting in my 2 cents for why I really liked __version__ and am sad to see it go.

[davidism]

@dwreeves I don't know your specific use case, but you could consider feature detection over version sniffing if possible. I was able to help @sirosen at the PyCon sprint yesterday see how to use some much simpler code (a single if key in args) to wrap some signature changes (a non-trivial compat) that still accomplished what he was previously looking at the version for. I'm still at the sprint right now in room 309, if you happen to be here. Other techniques include try: new; except Error: old and if hasattr. I'm happy to discuss specific techniques for your needs if you open a discussion or ask on our Discord.

[dwreeves]

Thanks! I will probably take you up on that as I start getting around to finalizing rich-click 1.9.0 and I run into things that get tricky. I'm already in the Discord as "dwreeves".

Right now our compat stuff is here: https://github.com/ewels/rich-click/blob/1.8.x/src/rich_click/_compat_click.py so every reference to one of those constants across the code is a place where we needed to do something for compatibility purposes. We're also very likely to remove Click 7.x support when we release 1.9.0.

Won't derail the thread further and I'll get back to you once we are at a more final stage of things.

[sirosen]

I proposed the better pattern as doc over here: #2929

Feature detection can be tricky, but it's basically always possible. We reach for the version number because it's there, but it is definitely more brittle than other techniques. If you take away the version number as an option for yourself and try to solve the problem without it, you will probably find your way to a better solution.

If you can't figure out how to avoid sniffing the version, show up in discord or discussions and describe what you're trying to accomplish -- people are always nice and willing to help if you put in the effort as a user to explain your situation and keep yourself open to alternative solutions.