You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The posthoganalytics package is built as a mirror of the posthog SDK package. A few SDK-internal runtime imports still used absolute posthog imports, which can resolve to a host application's local posthog package instead of the SDK mirror.
This changes those self-imports to relative imports so both the posthog and posthoganalytics packages resolve their own module state correctly.
💚 How did you test it?
uv run pytest posthog/test/test_contexts.py posthog/test/integrations/test_celery_integration.py -q
📝 Checklist
I reviewed the submitted code.
I added tests to verify the changes.
I updated the docs if needed.
No breaking change or entry added to the changelog.
If releasing new changes
Ran sampo add to generate a changeset file
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
This PR was prepared with the pi coding agent. The issue was identified while testing a dependency upgrade in the PostHog monorepo: posthoganalytics.new_context() could import a host application's posthog package through an SDK-internal absolute import. The chosen fix is to keep SDK self-references relative instead of adding compatibility globals to the host application.
This file was already modified to fix posthog.flush() → from .. import flush, but from posthog import contexts on this same line wasn't converted. The same mirror-resolution risk applies here: if an application's own posthog package is on sys.path, this import can resolve to the wrong module. Based on the AGENTS.md guidance added in this PR and the same pattern fixed elsewhere, this should also be a relative import: from .. import contexts.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
💡 Motivation and Context
The
posthoganalyticspackage is built as a mirror of theposthogSDK package. A few SDK-internal runtime imports still used absoluteposthogimports, which can resolve to a host application's localposthogpackage instead of the SDK mirror.This changes those self-imports to relative imports so both the
posthogandposthoganalyticspackages resolve their own module state correctly.💚 How did you test it?
📝 Checklist
If releasing new changes
sampo addto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
This PR was prepared with the pi coding agent. The issue was identified while testing a dependency upgrade in the PostHog monorepo:
posthoganalytics.new_context()could import a host application'sposthogpackage through an SDK-internal absolute import. The chosen fix is to keep SDK self-references relative instead of adding compatibility globals to the host application.