Skip to content

fix: stop shipping empty top-level wherobots/__init__.py (0.28.1)#69

Merged
ClayMav merged 1 commit into
mainfrom
chore/fix-namespace-collision-0.28.1
May 29, 2026
Merged

fix: stop shipping empty top-level wherobots/__init__.py (0.28.1)#69
ClayMav merged 1 commit into
mainfrom
chore/fix-namespace-collision-0.28.1

Conversation

@ClayMav
Copy link
Copy Markdown
Member

@ClayMav ClayMav commented May 28, 2026

Summary

  • Delete the empty wherobots/__init__.py from the dbapi source tree.
  • Bump version 0.28.00.28.1.

The bug

Both wherobots-python-dbapi 0.28.0 and wherobots-python-sdk 0.2.0 claim ownership of wherobots/__init__.py:

  • dbapi's was a 0-byte file (looks like an old setuptools leftover).
  • sdk's is a 1.7 KB file that re-exports the public API (WherobotsJob, WherobotsConfig, enums, models, …).

When both wheels land in the same environment, whichever installs last wins. The default pip install wherobots-python-dbapi wherobots-python-sdk ordering puts dbapi last → its empty __init__.py overwrites sdk's → from wherobots import WherobotsJob raises ImportError. from wherobots.db import … keeps working in either order because submodule imports bypass the parent's __init__.py, so dbapi-only consumers (and airflow-providers-wherobots, which only uses wherobots.db.*) aren't affected.

The fix

Remove the empty file from dbapi's source. wherobots/ then becomes a PEP 420 implicit namespace package from dbapi's perspective; the Jobs SDK's __init__.py is the canonical one whenever both packages are installed. dbapi's exports live entirely under wherobots.db.*, which is unaffected.

Verified

Built the wheel locally and tested all three install orderings against wherobots-python-sdk==0.2.0 from PyPI:

Order from wherobots import WherobotsJob from wherobots.db import connect, Region
dbapi first, sdk second
sdk first, dbapi second
both in one pip install

Existing tests: 72/72 unit tests pass.

Repro of the bug on the current PyPI release (before this PR)

uv venv /tmp/v && VIRTUAL_ENV=/tmp/v uv pip install wherobots-python-dbapi==0.28.0 wherobots-python-sdk==0.2.0
cd /tmp && /tmp/v/bin/python -c "from wherobots import WherobotsJob"
# ImportError: cannot import name 'WherobotsJob' from 'wherobots'

Test plan

  • CI green (lint + tests across 3.10–3.14)
  • After merge + v0.28.1 tag, confirm pip index versions wherobots-python-dbapi shows 0.28.1 and the wheel contents no longer include wherobots/__init__.py
  • Re-run the side-by-side install repro against the published 0.28.1

The dbapi source tree contained an empty `wherobots/__init__.py`, which
hatchling included in the built wheel. `wherobots-python-sdk` (the Jobs
SDK) ships its own non-empty `wherobots/__init__.py` re-exporting
`WherobotsJob`, `WherobotsConfig`, the enums, models, etc.

When both wheels are installed into the same environment they fight over
that file. Whichever wheel pip installs last wins. In the common case
(`pip install wherobots-python-dbapi wherobots-python-sdk`) dbapi's
empty file wins and `from wherobots import WherobotsJob` raises
ImportError. `from wherobots.db import ...` keeps working in both orders
because submodule imports bypass the parent `__init__.py`, so dbapi-only
consumers are not affected — and neither is `airflow-providers-wherobots`,
which only uses `wherobots.db.*`.

Remove the empty file so `wherobots/` becomes a PEP 420 implicit
namespace package from dbapi's side. The Jobs SDK's real `__init__.py`
remains the canonical one whenever both packages are installed.

Verified with three install orderings — dbapi first, sdk first, both in
one command — that `from wherobots import WherobotsJob` and `from
wherobots.db import connect, Region` succeed in all of them after this
change.
@ClayMav ClayMav requested a review from a team as a code owner May 28, 2026 20:24
@ClayMav ClayMav requested a review from sfishel18 May 28, 2026 20:24
@ClayMav ClayMav merged commit e24d672 into main May 29, 2026
7 checks passed
@ClayMav ClayMav deleted the chore/fix-namespace-collision-0.28.1 branch May 29, 2026 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants