feat: explicit exports

[flying-sheep]

Also get rid of the __version__ attribute, I really want to discourage people from using that over importlib.metadata.version. Versions are properties of distributions (PyPI packages), not import packages, and there is a canonical way in the stdlib to retrieve them using the distribution name. This is often the same, but doing things right makes things way less confusing when it isn’t the same.

Also regarding __version_tuple__: If people want a structured version, they can depend on packaging and parse the version using packaging.version.Version. It’s extremely fast and all our packages import packaging anyway at import time.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.47%. Comparing base (a77c3d6) to head (17bb3b5).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #10      +/-   ##
==========================================
+ Coverage   97.43%   97.47%   +0.04%     
==========================================
  Files           3        3              
  Lines         117      119       +2     
==========================================
+ Hits          114      116       +2     
  Misses          3        3              

Files with missing lines	Coverage Δ
src/scverse_misc/__init__.py	100.00% <100.00%> (ø)
src/scverse_misc/_deprecated.py	100.00% <100.00%> (ø)
src/scverse_misc/_extensions.py	96.34% <100.00%> (+0.04%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ilia-kats]

I'd strongly prefer keeping __version__ and __version_tuple__ around. importlib.metadata tends to be quite a bit slower (e.g. astral-sh/ruff#15671), in addtion to multiple other reasons for keeping __version__ around (this discussion is quite illuminating). __version__ is also still mentioned in the official packaging guide.

If users of the package prefer importlib.metadata, they are free to use it, but keeping __version__ and __version_tuple__ around doesn't really cost anything.

Looks good otherwise.

[flying-sheep]

I’m 100% convinced that accessing __version__ is almost always a bad idea (I do it in session-info2 since I want to capture everything, and as of 5 years ago some ancient conda packages still didn’t properly package standard metadata, but I haven’t seen it since and might remove that soon)

If I don’t completely misremember, I wrote that part of the official packaging guide, and intentionally chose the wording “many projects also choose” to clearly point out that that’s not a standard.

I’ve read that discussion, and I’ve had long discussions with Isaac about this: he was focused on the niche use case “have multiple editable versions of packages in an environment and frequently switch between them via git switch”, which, uh, you could just do differently.

If you care about 30ms added import time, you should probably rewrite your tool in not-Python.

My firm opinion: anyone who wants runtime versions should engage with the standards process to get runtime metadata. The PyPA is very open to do this, but nobody ever cared enough to make a PEP.