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

add chap --version #7

Merged
merged 4 commits into from
May 20, 2023
Merged

add chap --version #7

merged 4 commits into from
May 20, 2023

Conversation

jepler
Copy link
Owner

@jepler jepler commented Apr 6, 2023

A __version__ file is already created/managed by setuptools_scm. I'm not wedded to this tool, I chose it out of familiarity.

click has an easy way to add a --version flag, though the way to apply it to a MultiCommand is opaque.

For now I make version numbers just by using the "draft a new release" function on the github website. I do intend to adhere to semver, if I ever feel like this reaches a "version 1" status, fwiw.

Closes: #6

@peterkaminski I can't directly request review from you but wouldn't mind you taking a look since you expressed the idea in the first place.

@peterkaminski
Copy link
Contributor

Hmm, I did a git checkout issue6, and the first time I tried python -m chap --version, I got this error:

"RuntimeError: 'chap' is not installed. Try passing 'package_name' instead."

Trying python -m chap --help did the right thing, with no error.

So I did pip install -e . (thanks for that from the other issue, I didn't know about install -e before), and I think the only new thing that did was build a wheel for chap:

Created wheel for chap: filename=chap-0.2.1.dev2+g1e2fcf9-0.editable-py3-none-any.whl size=3029 sha256=a1eff20267876d01c5d882c2baa54b41475060d660e4af58cc69823978fa9e22

That created the __version__.py file, and then it worked.

I presume that's all to be expected, but I haven't played around right in this neighborhood of Python before. Is there something short to document? Or should it have been obvious to me?

Other than that, looks good to me!

@jepler
Copy link
Owner Author

jepler commented Apr 6, 2023

It's "python -m chap" the way your were invoking it before that? Hm.

I don't like having version files committed to git, since it's the tags that should hold the version information. But the setuptools_scm way of generating __version__ requires the installation process to be done. And this info becomes out of date, doing a "git pull" alone doesn't lead to an update of the generated version file, only invoking the package build does.

I'll have to think further about this, if version is useful to report then I wouldn't want it to be stale for "pip install -e" style users.

@peterkaminski
Copy link
Contributor

It's "python -m chap" the way your were invoking it before that? Hm.

I think you already know this, but to be abundantly clear, I'm using python -m chap on the version cloned from github.

For the pypi package, after pip install chap, I run it with just chap.

I definitely agree that there should be a single source of truth for the version number, and that it would be nice if it were the git tags. I'm not sure that's achievable, which is why people do the process I talked about in #6 -- have a release utility that atomically sets both the version in the source code and the git tag at the same time.

But if there's a better way, I'm all for it!

this still doesn't fix the thing where someone might be in a fork
that doesn't have the tags of github.com/jepler/chap but I can't fix
everything.
@peterkaminski
Copy link
Contributor

Thank you!

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 this pull request may close these issues.

Add --version
2 participants