You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using a package versioning helper such as setuptools_scm, it is quite natural to write, in a package's toplevel __init__.py, something like
from ._version import version as __version__
(assuming one uses setuptools_scm's write_to option rather than pkg_resources, as the latter can be quite slow).
Currently, pyflakes complains that __version__ is an unused name. Obviously, one can placate pyflakes by writing (over two lines) from . import _version; __version__ = _version.version, but that seems a bit silly: I would instead suggest that pyflakes consider all global-level dunders as automatically used (in the sense "they have a special or metadata role anyways"), even if they appear not so.
The text was updated successfully, but these errors were encountered:
pyflakes currently requires using __all__ in __init__.py to avoid unused name errors (I'm not sure, but I think it's a good idea for even __version__ to go in __all__).
Actually, I think putting __version__ in __all__ is a pretty bad idea: someone who does from foo import * (say, in the bar) module will now also set bar.__version__ (as it's a string, it doesn't keep track of its origin module, so third party tools will use that as the bar module version.
(Yes, import * is a bad idea but we're talking about __all__ anyways...)
When using a package versioning helper such as setuptools_scm, it is quite natural to write, in a package's toplevel
__init__.py
, something like(assuming one uses setuptools_scm's
write_to
option rather than pkg_resources, as the latter can be quite slow).Currently, pyflakes complains that
__version__
is an unused name. Obviously, one can placate pyflakes by writing (over two lines)from . import _version; __version__ = _version.version
, but that seems a bit silly: I would instead suggest that pyflakes consider all global-level dunders as automatically used (in the sense "they have a special or metadata role anyways"), even if they appear not so.The text was updated successfully, but these errors were encountered: