Add Package to the frame when creating stacktrace

[grongor]

When creating stack trace, the Package field is completely omitted, so that information isn't present in the Sentry UI withing Exception box.

I tried simpler approach first: to just fill Package field with the same content as the Module field, and the result is identical (I guess Sentry server/frontend does the same thing I did here with stripping content before last slash), but this way we send smaller payload...I'm not sure which you prefer but I just wanted to mention this fact so you can decide on your own.

Here are before and after screenshots from my dummy application:

[rhcarvalho]

This has intrigued myself in the past, I'll try to explain.

The Sentry protocol is language agnostic and exists for much longer than Go has had Modules. The naming is unfortunate, but Module and Package in sentry.Frame do not carry the meanings of "Go Module" and "Go Package".

---

Module in Sentry is roughly what a "Go Package" is (similar to a Python module).

Package is used in some platforms, but not all. For example, in Java it refers to a JAR file, in .NET to an assembly and in C/C++ to a dynamic library. In Go, the closest match would probably be a "Go Module".

As you noticed, setting Package affects how the Sentry UI renders stack traces. Because Go Package names are so closely related to Go Module names (the module name is always a prefix of all packages it contains), setting Frame.Package to the full module path (or similar) makes the stack trace more verbose and doesn't add new information.

Zooming in and underlining a few names in your screenshot above, note how the "within <package name>" doesn't add any new information to what was already present in the same line:

I believe for now Frame.Package is not useful for Go stack traces, but open to hear ideas, perhaps we find a good use for it. It remains in the SDK for any usage of the SDK types to send custom event payloads.

---

References:
https://develop.sentry.dev/sdk/event-payloads/stacktrace/
https://github.com/getsentry/relay/blob/cb4af7b2c50c1513ea084a1f899e835166a5a7ae/relay-general/src/protocol/stacktrace.rs#L52-L66

[grongor]

Thanks for the lengthy explanation. Yes, I understand the fact that you need to map language-specific concepts so some artificial Sentry concepts (which might be derived from eg. Java) and so the naming might be strange to Go developers, or maybe the whole concepts.

I know that adding filling the Package field won't add any new information that wasn't present there before, but it makes it more obvious/accessible. At least for me personally when I look at the second screenshot I see the package immediately, it stands out. Looking for it in the path is a bit more complicated. I also don't think that a bit longer stack trace is an issue, as package names are generally short in Go, and also...nobody really views Sentry in 800x600 window I hope :D

But anyway, I won't mind if you decide not to merge this - I understand the duplicity argument. Thank you for your time.

[rhcarvalho]

@grongor in case you want to have this and other customizations to your events you can write an EventProcessor that walks event stack traces and set Frame.Package (and in this case you can always derive it from Frame.Module).

[grongor]

@grongor in case you want to have this and other customizations to your events you can write an EventProcessor that walks event stack traces and set Frame.Package (and in this case you can always derive it from Frame.Module).

Thanks for the suggestion. Yeah, I know there are ways (it's great that it's so extensible and people are not limited by the SDK ❤️ ), I just thought that the "default" should be to include it :) I'll do just that for my projects (as I do for other fixes like for #378 ).