-
Notifications
You must be signed in to change notification settings - Fork 500
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
(2) Move capture_*
from Hub to Client
#2555
(2) Move capture_*
from Hub to Client
#2555
Conversation
…y-python into antonpirker/refactor-hub
capture_*
from Hub to Clientcapture_*
from Hub to Client
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.
LGTM 🌟 Left some suggestions.
@antonpirker ok I understand what you're doing but WHY are you moving these things to client and how does it help you with the further refactor? |
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.
Overall I don't understand the motivation for this change. Much of these methods will move to Scope
according to the RFC and the Client should be fairly similar to before with just the one capture_event
(that serializes and sends to transport).
capture_exception|message|transaction
etc will be done by the new Scope.
sentry_sdk/client.py
Outdated
message, # type: str | ||
level=None, # type: Optional[str] | ||
scope=None, # type: Optional[Scope] | ||
top_scope=None, # type: Optional[Scope] |
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.
I would not add top_scope
here.
If you see the RFC, the 3 scopes will be processed by Scope.capture_event
.
The managing of the scopes is currently done by the Hub and will be moved to Scope later. I think the client should just get one scope as before and the merging will be moved later from Hub -> Scope.
You are right. I took the wrong turn here. Makes total sense to move the functions to the the scope. :-) |
…scopes the hub is removed and the root level API directly calls it on the scope
Moved some functionality from Hub to Client:
Capture Event:
capture_event
from Hub to Clientcapture_event
in Scope that callscapture_event
in Clientcapture_event
in Hub call the newcapture_event
in ScopeCapture Exception:
capture_exception
in Scopecapture_exception
in Hub call the new one in ScopeCapture Message:
capture_message
in Scopecapture_message
in Hub call the new one in Scoperenamed
**scope_args
to**scope_kwargs
because it contains keyword arguments.moved
_update_scope
from Hub to Scope and renamed it to_merge_scopes
This is preparation work for refactoring how we deal with Hubs and Scopes in the future.
Its properly easier to reason about this change when checking out the branch than looking at the diff.
Depends on: #2578 (please review the linked one first)