-
-
Notifications
You must be signed in to change notification settings - Fork 262
Export Core Supabase Classes and Functions Explicitly via __all__ #691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR Type: Enhancement
PR Summary: This pull request introduces an enhancement to the Supabase Python SDK by explicitly defining its public API. It achieves this through the addition of an all list in the init.py file, which specifies the classes and functions that are intended for public use. This change is aimed at improving code quality by addressing issues related to the import visibility of unexported members, which can lead to warnings or errors from tools like PyRight.
Decision: Comment
📝 Type: 'Enhancement' - not supported yet.
- Sourcery currently only approves 'Typo fix' PRs.
✅ Issue addressed: this change correctly addresses the issue or implements the desired feature.
No details provided.
✅ Small diff: the diff is small enough to approve with confidence.
No details provided.
General suggestions:
- Ensure that all newly exported members are documented appropriately, highlighting their purpose and usage within the SDK.
- Consider adding a brief comment above the all declaration explaining its purpose for future maintainers or contributors who might not be familiar with this Python convention.
- Review the list of exported members to ensure it's comprehensive and only includes those intended for public use, to avoid any unintended exposure of internal functionality.
Thanks for using Sourcery. We offer it for free for open source projects and would be very grateful if you could help us grow. If you like it, would you consider sharing Sourcery on your favourite social media? ✨
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the link! It was helpful in understanding the PR
Ah mind running |
Yep I can do it tmr |
Hi @WesleyYue , thanks for addressing this -- this looks useful. I'm also making some changes in another branch and it would be cool to rebase it on top of your changes <3 My changes aren't urgent and are meant to be more of a discussion seeking feedback on some design changes so I'll likely open a draft PR initially, but let me know whenever this is ready to land. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #691 +/- ##
==========================================
+ Coverage 44.34% 44.51% +0.16%
==========================================
Files 13 13
Lines 327 328 +1
==========================================
+ Hits 145 146 +1
Misses 182 182 ☔ View full report in Codecov by Sentry. |
Thanks for this PR @WesleyYue. The changes should be available in release 2.3.6 of the supabase-py package. |
What kind of change does this PR introduce?
This PR introduces a code quality improvement to the Supabase Python SDK.
What is the current behavior?
Currently, the Supabase Python SDK does not explicitly define its public API using the all variable in its init.py file. This omission can lead tools like PyRight to raise warnings or errors about importing private members, like the components under
_sync
. See https://arc.net/l/quote/juxuoghjWhat is the new behavior?
By specifying an all list in the init.py file of the Supabase Python SDK, we explicitly declare the public interface of the module. This declaration prevents PyRight and similar tools from complaining about the import of private members, thus clearing warnings/errors related to import visibility.