Skip to content

Drop the re-exports so there is one import path per symbol - #241

Merged
cboulay merged 1 commit into
devfrom
cboulay/one-import-path
Sep 7, 2026
Merged

Drop the re-exports so there is one import path per symbol#241
cboulay merged 1 commit into
devfrom
cboulay/one-import-path

Conversation

@cboulay

@cboulay cboulay commented Sep 7, 2026

Copy link
Copy Markdown
Member

Follow-up to #240, taking you up on the offer to break 3.8.0/3.8.1's added surface rather than live with two import paths.

What was wrong with the re-exports

3.8.1 re-exported baseproc's resolvers and suppress_axis_deprecation from ezmsg.sigproc.util.* for compatibility with 3.8.0, which had defined them there. That compatibility bought less than the confusion it cost.

The concrete failure: while 3.8.0 was current there were two different ContextVars behind the same name. ezmsg-event entered baseproc's suppression context, sigproc's warning checked sigproc's — so nothing was suppressed and the forwarding warned twice. CI caught it; my local editable install had masked it. The fix at the time was a four-line comment in event and learn explaining which of two mechanisms to reach for. That comment is what this PR deletes.

Both releases are a day old and none of these symbols existed before them.

The end state

symbol single source
resolve_chunk_dim, resolve_feature_dim, resolve_transform_dim, resolve_configured_chunk_dim, STREAMING_DIMS ezmsg.baseproc
suppress_axis_deprecation ezmsg.baseproc
AXIS_REMOVAL_VERSION, warn_axis_deprecated ezmsg.sigproc.util.deprecation

The remaining warn_axis_deprecated is not a re-export — it binds baseproc's to this distribution and its removal release, so ~27 call sites stay one line and every message agrees on when the setting goes away. Its docstring now says so explicitly.

The sample-message re-exports in util.message (SampleMessage, SampleTriggerMessage, is_sample_message) are untouched: those predate all of this and have real users.

Notes

Net −12 lines across 34 files; ruff collapsed the split imports back into single from ezmsg.baseproc import (...) blocks, so most files got shorter.

One import my rewrite pattern missed: util/channels.py used from .message import resolve_feature_dim — relative within util/, so it didn't match from .util.message import. Collection failed loudly and it's fixed.

Testing

4285 unit + 51 integration pass; ruff clean. Verified the surface is actually gone rather than just unused — ezmsg.sigproc.util.message and .deprecation no longer expose any resolver or the suppression context.

Downstream, ezmsg-event and ezmsg-learn now import suppression from baseproc and pin >=3.8.1; both suites pass against the real 3.8.1 wheel.

3.8.1 re-exported baseproc's resolvers and suppression from
`ezmsg.sigproc.util.*` for backwards compatibility with 3.8.0, which had
defined them there. That compatibility is worth less than the confusion it
buys: two import paths for one thing, and -- while 3.8.0 was current -- two
*different* ContextVars behind the same name, so a downstream package could
enter one suppression context and be silenced by neither. Both releases are a
day old and the symbols never existed before them.

From here:

* resolvers and suppress_axis_deprecation come from ezmsg.baseproc
* AXIS_REMOVAL_VERSION and warn_axis_deprecated stay in
  ezmsg.sigproc.util.deprecation

The remaining warn_axis_deprecated is not a re-export: it binds baseproc's to
this distribution and its removal release so ~27 call sites stay one line.

The sample-message re-exports in util.message are untouched; those predate all
of this and have real users.
@cboulay
cboulay merged commit ac96179 into dev Sep 7, 2026
14 checks passed
@cboulay
cboulay deleted the cboulay/one-import-path branch September 7, 2026 04:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant