Repository navigation
version_option module name and package name are not equivalent #2331
Description
Activity
- changed the title
[-][BUG] [click.version_option()] Module name and package name are not equivalent[/-][+]version_option module name and package name are not equivalent[/+]on Aug 2, 2022 FYI, I fixed this in Click Extra, where you can use the
{module_name}and{package_name}variables independently to form the version string printed by the--versionoption.For more details, see: https://kdeldycke.github.io/click-extra/version.html
Reacted by yancong@AndreasBackx This seems like a good candidate to be upstreamed to us. What do you think?
Reacted by Andreas BackxKind of feels like an AI comment. Regardless, you can look at pyproject.toml and you'll see the minimum Python version.
- changed the title
[-]version_option module name and package name are not equivalent[/-][+]`version_option` module name and package name are not equivalent[/+]on May 28, 2026 Based on #3527, I am going to close this.
As discussed in #3527 , we will not extend the
@version_optiondecorator.If you need something different than the default, you have to produce your own message. Or use the full-featured
@click_extra.version_optiondecorator from the Click Extra project.Reacted by yancong- added a commit that references this issue
on Jun 11, 2026 - linked a pull request that will close this issueFix `package_name` resolution when module differs from distribution name #3582
on Jun 11, 2026 - added a commit that references this issue
on Jun 14, 2026 - locked as resolved and limited conversation to collaborators
on Jul 24, 2026
Environment:
The click.version_option uses the module name to get the package version :
click/src/click/decorators.py
Lines 410 to 417 in 08f71b0
But module name and package name are not always equivalent. This could be crash when the module name not the same as the package name, eg. open-mmlab/mim#152