(2) Move `capture_*` from Hub to Client by antonpirker · Pull Request #2555 · getsentry/sentry-python

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker · 2023-12-01T10:06:25Z

Moved some functionality from Hub to Client:

Capture Event:
- moved capture_event from Hub to Client
- created new capture_event in Scope that calls capture_event in Client
- made capture_event in Hub call the new capture_event in Scope
Capture Exception:
- created new capture_exception in Scope
- made capture_exception in Hub call the new one in Scope
Capture Message:
- created new capture_message in Scope
- made capture_message in Hub call the new one in Scope
renamed **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)

…y-python into antonpirker/refactor-hub

…-capture

sentrivana

LGTM 🌟 Left some suggestions.

sl0thentr0py · 2023-12-12T14:13:48Z

@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?

sl0thentr0py

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.

sl0thentr0py · 2023-12-12T14:24:31Z

+ message, # type: str
+ level=None, # type: Optional[str]
+ scope=None, # type: Optional[Scope]
+ top_scope=None, # type: Optional[Scope]


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.

antonpirker · 2023-12-12T14:34:28Z

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

…mentation)

antonpirker added 10 commits November 29, 2023 16:08

Moved get_integration from Hub to Client
f2a4a3a

Moved add_breadcrumb from Hub to Scope
4869365

Moved session functions from Hub to Scope
e5f9e9d

Fixed import
a338099

Fixed Python 2.7 syntax
d900a1b

Merge branch 'master' into antonpirker/refactor-hub
0afb3ab

Give the client to the scope function. Want to establish a pattern.
fe77d04

Merge branch 'antonpirker/refactor-hub' of github.com:getsentry/sentr…
4ba7dce
…y-python into antonpirker/refactor-hub

Moved capture_* functions from Hub to Client
b15613a

Renamed scope_args to scope_kwargs
8331bd0

antonpirker changed the base branch from master to antonpirker/refactor-hubDecember 1, 2023 10:06

antonpirker added 3 commits December 1, 2023 11:10

oops
ce1759f

preserve old behavior when called from client directly (not from hub)
9a08b6e

update test
f9b8d5a

antonpirker marked this pull request as ready for review December 1, 2023 11:44

antonpirker requested a review from sentrivana December 1, 2023 11:44

antonpirker mentioned this pull request Dec 1, 2023
(3) Move tracing related functions from Hub to Scope #2558
Merged

antonpirker added 3 commits December 4, 2023 16:21

Merge branch 'master' into antonpirker/refactor-hub-capture
d233ae5

Merge branch 'master' into antonpirker/refactor-hub
2932adc

Merge branch 'antonpirker/refactor-hub' into antonpirker/refactor-hub…
3a7af73
…-capture

antonpirker changed the title ~~Move capture_* from Hub to Client~~(2) Move capture_* from Hub to ClientDec 4, 2023

Base automatically changed from antonpirker/refactor-hub to masterDecember 6, 2023 08:02

Merge branch 'master' into antonpirker/refactor-hub-capture
345c419

sentrivana approved these changes Dec 6, 2023
View reviewed changes

Comment threadsentry_sdk/client.py Outdated
Comment threadsentry_sdk/hub.py Outdated
Comment threadsentry_sdk/client.py Outdated

antonpirker changed the base branch from master to feat/new-scopesDecember 11, 2023 11:32

antonpirker changed the base branch from feat/new-scopes to antonpirker/refactor-hubDecember 11, 2023 11:33

Base automatically changed from antonpirker/refactor-hub to feat/new-scopesDecember 11, 2023 11:54

antonpirker added 2 commits December 11, 2023 15:19

_update_scope belongs into the scope not the client
bb3250a

Made top_scope separate parameter
3a22dd6

sl0thentr0py added the scope refactor label Dec 12, 2023

sl0thentr0py requested changes Dec 12, 2023
View reviewed changes

antonpirker added 5 commits December 13, 2023 14:06

Hub calls capture_* on scope that calls it on client. Later with new …
c78b1f5
…scopes the hub is removed and the root level API directly calls it on the scope

Merge branch 'feat/new-scopes' into antonpirker/refactor-hub-capture
0901e72

Moved everything to scope and only have capture_event in client
269fd56

small fix
0354065

Updated test
3d5825e

antonpirker commented Dec 13, 2023
View reviewed changes

Comment threadtests/test_client.py Outdated

antonpirker added 7 commits December 13, 2023 16:53

Fixed test
4e78d1f

Fixed test
ba72216

Fixed test for old python
c5a7ae7

Formatting
bbb93e6

Passing the client as separate argument and updating api docs.
12e632d

ApiDocs
eb56a12

Fix
074a9ef

antonpirker requested review from sentrivana and sl0thentr0py December 14, 2023 12:47

sentrivana approved these changes Dec 14, 2023
View reviewed changes

sl0thentr0py requested changes Dec 18, 2023
View reviewed changes

Comment threadsentry_sdk/scope.py Outdated

Remove condition from _merge_scope (also not present in current imple…
6733114
…mentation)

antonpirker requested a review from sl0thentr0py December 19, 2023 07:39

sl0thentr0py approved these changes Dec 19, 2023
View reviewed changes

antonpirker merged commit 79e15f5 into feat/new-scopesDec 19, 2023

antonpirker deleted the antonpirker/refactor-hub-capture branch December 19, 2023 11:20