Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

path and python version values for version message formatting #1756

Open
snosratiershad opened this issue Jan 15, 2021 · 6 comments · May be fixed by #2681
Open

path and python version values for version message formatting #1756

snosratiershad opened this issue Jan 15, 2021 · 6 comments · May be fixed by #2681

Comments

@snosratiershad
Copy link

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.

@davidism
Copy link
Member

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="...").

@davidism davidism changed the title pre-Pull Request: path and python version values for version message formatting. path and python version values for version message formatting Jan 15, 2021
@snosratiershad
Copy link
Author

snosratiershad commented Jan 16, 2021

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.

@snosratiershad
Copy link
Author

After 7 days again, What can I do? :)

@jcrotts
Copy link
Contributor

jcrotts commented Feb 18, 2021

Feel free to open a PR, it's easier to discuss that way! Just be aware it may not make it into Click.

kdeldycke added a commit to kdeldycke/click-extra that referenced this issue Sep 4, 2023
@kdeldycke
Copy link
Contributor

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

@snosratiershad
Copy link
Author

I'll follow-up this issue with a PR, as @jcrotts suggested. Sorry for my irresponsibility on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants