jorisvandenbossche commented on code in PR #644:
URL: https://github.com/apache/arrow-nanoarrow/pull/644#discussion_r1814542858
##########
python/src/nanoarrow/__init__.py:
##########
@@ -75,7 +77,8 @@
from nanoarrow.array import array, Array
from nanoarrow.array_stream import ArrayStream
from nanoarrow.visitor import nulls_as_sentinel, nulls_forbid, nulls_separate
-from nanoarrow._version import __version__ # noqa: F401
+
+__version__ = importlib.metadata.version("nanoarrow")
Review Comment:
> is there any issues with versioning in this way? Is there any cost to
importing `importlib.metadata` by default?
I would personally advise to not use `importlib.metadata.version` for
creating the `__version__` attribute, because it will add some avoidable
overhead (without testing I don't know how big this would be, but in general we
want to keep the import as lean as possible, and this seems unnecessary
overhead to scan installed packages, when the `__version__` attribute can (in
the built packages, i.e. injected during build-time) simply be a static
string).
In addition, when using editable installs, this might also not always work
as expected (the metadata version does not update automatically).
> As far as whether or not this approach is viable, here is the Python
packaging documentation:
>
>
https://packaging.python.org/en/latest/discussions/single-source-version/#single-source-version
Note that that page does not actually mention to use
`importlib.metadata.version` to populate `__version__`, just that there is a
desire that those return the same thing.
There has been a long discussion on this the last months at
https://discuss.python.org/t/please-make-package-version-go-away/58501, that
resulted in the updated page linked above (it's long, don't read it all ;), but
I do see that it does actually have some discussion on the overhead, estimated
there to be 20-40ms (although it might also depend on how big your environment
is))
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
