[Feature] path and python version values for version message formatting
A lot of programs are using the path of package and/or the Python version in the text message formatting of the version option. For example virtualenv:
virtualenv 20.2.2 from /home/salar/.local/lib/python3.8/site-packages/virtualenv/__init__.py
mkdocs:
mkdocs, version 1.1.2 from /home/salar/.local/lib/python3.8/site-packages/mkdocs (Python 3.8)
pylint:
pylint 2.6.0
astroid 2.4.2
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
[GCC 10.2.0]
I think it will be good, to add python version and path values in message formatting. I tried it, and before pull request, I should to create an issue as Feature request. Thanks for any reviews, Salar.
Adding these seems reasonable, but I'm a bit worried about adding too many values to satisfy everyone. Should the path be to the executable entry point, or to the Python module? Should the Python version be the verbose string, or the basic version? If basic like mkdocs, should it only be X.Y? Note that you can already add exactly the information you need by customizing version_option(message="...").
Adding these seems reasonable, but I'm a bit worried about adding too many values to satisfy everyone. Should the path be to the executable entry point, or to the Python module? Should the Python version be the verbose string, or the basic version? If basic like mkdocs, should it only be X.Y? Note that you can already add exactly the information you need by customizing
version_option(message="...").
Hi.
It's a understandable problem, but I think it's can be handled.
About the path, it's just like prog_name and package_name. so we can add prog_path and package_dir, and Click will try to find them from built-in __file__ variable.
But about Python version, we can add a parameter about env_version. And if it's not provided, for example Click can use the standard verbose version_info.
Thanks for reviewing, and please give me information about what should we do. Salar.
After 7 days again, What can I do? :)
Feel free to open a PR, it's easier to discuss that way! Just be aware it may not make it into Click.
For the record, I addressed this issue in Click Extra 4.7.0.
Now you can:
from click_extra import command, extra_version_option
@command
@extra_version_option(
message="{prog_name} {version}, from {module_file} (Python {env_info[python][version]})"
)
def custom_env_info():
pass
And get the custom version string you are looking for:
$ custom-env-info --version
custom-env-info 4.7.0, from /home/user/click-extra/click_extra/testing.py (Python 3.11.5)
More info at: https://kdeldycke.github.io/click-extra/version.html
I'll follow-up this issue with a PR, as @jcrotts suggested. Sorry for my irresponsibility on this issue.