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 rich.__version__ #15

Closed
wookayin opened this issue Mar 8, 2020 · 9 comments
Closed

Add rich.__version__ #15

wookayin opened this issue Mar 8, 2020 · 9 comments

Comments

@wookayin
Copy link

wookayin commented Mar 8, 2020

rich should have __version__ property.

AttributeError: module 'rich' has no attribute '__version__'

This is a common python convention to tell package version easily.

@willmcgugan
Copy link
Collaborator

I use poetry to do packaging, which recommends pkg_resources to get the version from meta data. They initially recommended dropping __version__ entirely. Fortunately there some to be some movement on that front, and we may get __version__ back.

@wookayin
Copy link
Author

wookayin commented Mar 8, 2020

Thanks for the feedback. But why is it closed (it's still unimplemented)? Even though poetry is used, we could add this property with a workaround.

@willmcgugan
Copy link
Collaborator

Keeping the version in two places is problematic. But if poetry hasn't got a solution when I release a 1.0 version, that's what I might have to do. In the meantime, the lack of a __version__ isn't going to break anything that I know of, and pkg_resources.get_distribution("rich").version can be used to get the version.

@thebigmunch
Copy link

Just a note. For Python 3.8+, importlib.metadata should probably be used instead. And the importlib_metadata backaport exists for other Python 3 versions. It was created to replace pkgresources metadata functionality.

Here's how I use it to deduplicate my package metadata. I use poetry, too, and I couldn't wait any longer. I already had that module and was manually updating it.

@willmcgugan
Copy link
Collaborator

I may end up doing something similar...

@LewisGaul
Copy link

LewisGaul commented Mar 20, 2022

Thanks for the feedback. But why is it closed (it's still unimplemented)? Even though poetry is used, we could add this property with a workaround.

Still seems to be missing __version__, if the intention was for it to be added by v1.0 then perhaps this issue should have been left open...

@willmcgugan
Copy link
Collaborator

Don't know where you got that idea from.

@LewisGaul
Copy link

I didn't mean to sound adversarial! It was your message above that gave me this impression:

Keeping the version in two places is problematic. But if poetry hasn't got a solution when I release a 1.0 version, that's what I might have to do.

Personally I agree with the OP that it's pretty standard to provide this, but it's up to you of course.

@willmcgugan
Copy link
Collaborator

It was a standard of sorts, but now importlib is recommended, and __version__ is a convenience.

Unless poetry has an answer to this that doesn't require a backport of importlib, I'm afraid there is no motivation to change it.

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

No branches or pull requests

4 participants