feat(logging): shared logger skeleton with Rule extension

[timtreis]

Shared logger for scverse packages. One scverse parent logger + single handler (rich if installed, else plain); package loggers are children, so verbosity/rich/rules are controlled centrally.

from scverse_misc.logging import get_logger, config, Rule

log = get_logger("spatialdata")        # real logging.Logger, child of "scverse"
config.verbosity = "info"              # central, all packages
config.add_rule(MyRule())              # 0..N rules

Sole extension point is Rule (keep/rewrite). Ships Elapsed/Deep universal rules (on by default, no-ops until used). get_logger(name, timed=True) opts into scanpy-style time=/deep=/.hint() + a datetime return.

Packages keep their behavior with a local rule

spatialdata-plot — report the public entry point instead of internal helpers:

from contextvars import ContextVar
_ctx: ContextVar[str] = ContextVar("ctx", default="")

class ContextPrefix(Rule):
    def rewrite(self, message, record):
        ctx = _ctx.get()
        return f"{ctx}: {message}" if ctx else message

config.add_rule(ContextPrefix())   # render_* entry points set _ctx

decoupler — always-on timestamp:

from datetime import datetime

class Timestamp(Rule):
    def rewrite(self, message, record):
        return f"{datetime.now():%H:%M:%S} | {message}"

config.add_rule(Timestamp())

design proposal for discussion

[codecov]

Codecov Report

❌ Patch coverage is 97.50000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.67%. Comparing base (de3484b) to head (2f19905).

Files with missing lines	Patch %	Lines
src/scverse_misc/logging.py	97.48%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
+ Coverage   92.63%   93.67%   +1.03%     
==========================================
  Files          11       12       +1     
  Lines         584      743     +159     
==========================================
+ Hits          541      696     +155     
- Misses         43       47       +4     

Files with missing lines	Coverage Δ
src/scverse_misc/__init__.py	100.00% <100.00%> (ø)
src/scverse_misc/datasets/__init__.py	100.00% <ø> (ø)
src/scverse_misc/logging.py	97.48% <97.48%> (ø)

🚀 New features to boost your workflow:

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

[grst]

Can we integrate that with the global scverse-misc config handling?

[timtreis]

Partially (except the rule logic), yeah. But I think then we should promote pydantic as a core dep, no? Otherwise we need a fallback for that too here

[grst]

yeah, this would make logging depend on the settings dependency group which would be ok IMO.

[timtreis]

I feel like we're about to create a complicated net of various dependency groups that depend on dependency groups. Could we maybe be somewhat opinionated here? 👀 Like do we really want to add a new dependency group for every feature we add? While that's at least only slightly annoying, making them inter-dependent feels a lot

[grst]

since logging has no additional dependencies, logging/settings would be a single one.

[grst]

why does it even depend on anndata?

[ilia-kats]

#40

[grst]

ok, but why is it not part of the datasets dependency group?

[ilia-kats]

Excellent question : ) I didn't get around to reviewing that PR before it was merged, but my assumption would be that if a package is downloading anndata files, it will be using them and will depend on anndata anyway, so scverse-misc shouldn't need anndata anywhere in its dependencies. Same with spatialdata.

[flying-sheep]

scverse-misc now hard-depends on anndata

Actually let’s undo that, we now have a circular dependency. Not good!

Like do we really want to add a new dependency group for every feature we add?

Yes, very much so!

And why does this PR add more hard dependencies? I’m a fan of keeping things modular. Adding more and more hard deps is exactly the “slippery slope” I feared in making this package, and keeping it modular (and adding good tests for the powerset of that modularity!) keeps that somewhat in check.

making them inter-dependent feels a lot

Let’s not then. Let’s add a logging extra that depends on pydantic and not pydantic-settings.

[grst]

This would make it write to stderr by default. Do we want that?

Suggested change

	return RichHandler(show_path=False, show_time=False) # rich renders the level itself
	return RichHandler(console=Console(stderr=True), show_path=False, show_time=False) # rich renders the level itself

[flying-sheep]

Regarding the design: I don’t like that rewrite actually changes the stored message – logging should separate context, message, and formatting.

E.g. people attaching a JSON log handler to decoupler’s logger should get {"message": ..., "extra": {"timestamp": ...}} or so (maybe flattened extra), not {"message": "2026-... | ..."}.

So I think this should be a two step process:

1. add a hook that adds minimal data to extra. It should avoid any string wrangling and just do the absolute minimum to amend the data that’s stored (which also happens to be faster)
2. configure the formatter for text logging to include the extra fields. We should use style="{" as nobody remembers how to use ancient C style formatting while we’re all using f-strings daily.