Clean up __init__.py -- especially remove __version__

[jagerber48]

• Closes # (insert issue number)

• Executed pre-commit run --all-files with no errors

• The change is fully covered by automated unit tests

• Documented in docs/ as appropriate

• Added an entry to the CHANGES file

• Remove __author__. This is captured in pyproject.toml.

• Remove long docstring. Hopefully this docstring is essentially captured in README.rst

• Remove legacy "version" stuff. The modern strategy for users to get uncertainties version information at runtime is to do from importlib.metadata import version and run version('uncertainties').

The version import is breaking the read the docs build right now, so this will hopefully resolve that issue.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.37%. Comparing base (4a470e4) to head (f4b0743).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #257      +/-   ##
==========================================
+ Coverage   96.33%   96.37%   +0.04%     
==========================================
  Files          15       15              
  Lines        1909     1906       -3     
==========================================
- Hits         1839     1837       -2     
+ Misses         70       69       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[newville]

@jagerber48

Remove legacy "version" stuff. The modern strategy for users to get uncertainties version information at runtime is to do from importlib.metadata import version and run version('uncertainties').

-1 from me on removing uncertainties.__version__.

[jagerber48]

@newville More details on why -1 on removing __version__? The issue with readthedocs can be solved by using from importlib.metadata import version in conf.py as shown in this PR.

If downstream projects (is lmfit included here?) need the version number dynamically the modern practice is importlib.metadata like I described. It is a breaking change but would I'd like to make on some timescale I guess. We could save it for 4.0.

[newville]

@jagerber48 -1 on the concept of "modern practice" when it comes to any of the relentless churn that is Python packaging.

importlib.metadata was introduced in Python 3.8 but "provisional" until 3.10: https://docs.python.org/3/library/importlib.metadata.html

For me, this:

from importlib import metadata

import numpy, scipy, matplotlib, pandas, h5py, skimage, sklearn, pytest
import sphinx, datetime, boto3, requests, flask, astropy, sympy, lmfit
import jupyter, notebook

for mod in (numpy, scipy, matplotlib, pandas, h5py, skimage, sklearn, pytest,
            sphinx, boto3, requests, astropy, sympy, lmfit,
            notebook, flask, datetime, jupyter):
    dunder_version = getattr(mod, '__version__', 'no __version__')
   # thanks PyPA for making it this complicated!
    try:
        imlib_version = metadata.version(mod.__name__)
    except:
        imlib_version = 'no metadata.version'
    print(mod.__name__, dunder_version, imlib_version)

gives:

numpy 1.26.4 1.26.4
scipy 1.14.0 1.14.0
matplotlib 3.9.1 3.9.1
pandas 2.2.2 2.2.2
h5py 3.11.0 3.11.0
skimage 0.24.0 no metadata.version
sklearn 1.5.1 no metadata.version
pytest 8.2.2 8.2.2
sphinx 7.4.6 7.4.6
boto3 1.34.145 1.34.145
requests 2.32.3 2.32.3
astropy 6.1.1 6.1.1
sympy 1.13.0 1.13.0
lmfit 1.3.2 1.3.2
notebook 6.5.7 6.5.7
.../py:10: DeprecationWarning: The '__version__' attribute is deprecated and will be removed in Flask 3.1. Use feature detection or 'importlib.metadata.version("flask")' instead.
  dunder_version = getattr(mod, '__version__', 'no __version__')
flask 3.0.3 3.0.3
datetime no __version__ 5.5
jupyter no __version__ 1.0.0

An equal number of projects fail with both. FWIW, you would need to do metadata.version('scikit-image'), but I do not know how one would programmatically determine that from skimage.

And indeed,

import numpy as np
print(np.__version__)

has no obvious analog. Because metadata.version('package_name') is about "what packages did pip install on this system", not "what are the versions of these modules found at runtime".

The continual churn that is Python packaging is changing problems, but not solving them.

Again, -1 on dropping __version__.

[jagerber48]

Ok thanks for that additional detail. We can support both for now. I’ll close this shortly. There is other cleanup than can happen but at a later time.

I was inspired to make this PR in thinking about the rtd issue but that’s handled in #255

[jagerber48]

@newville what of __version_tuple__ and __version_info__? Can those be dispensed with? I don't know what they're for.

[jagerber48]

Nevermind, see #258