-
Notifications
You must be signed in to change notification settings - Fork 79
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
Don't configure automatically #219
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
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.
Generally looks good, I just want to confirm that none of the behaviour actually changes with this PR?
@@ -1228,3 +1238,7 @@ def sanitize_project_name(name: str) -> str: | |||
|
|||
def default_project_name(): | |||
return sanitize_project_name(os.path.basename(os.getcwd())) | |||
|
|||
|
|||
class LogfireNotConfiguredWarning(UserWarning): |
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.
should this be public?
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.
Currently we have a few warnings but none are public. I think that if we decide to make them public we should make a new logfire.warnings
module for them in a new PR.
No, the behaviour does actually change. We can have a deprecation period (1 week?) if you want but I'm not sure it's worth it. |
Deploying logfire-docs with Cloudflare Pages
|
Closes #194
Step 2 there isn't done but I realize now that it's not really a blocker, and there's strong demand for this change.
The implementation here is simple but not ideal. In particular
logfire.span
etc will still do a lot of processing which will slow things down and maybe even raise errors, it's just that the actual OTEL span will be a no-op. But makinglogfire.span
a proper no-op is nontrivial since it still needs to return a context manager with methods, and that work overlaps with #146. Optimizing this can be done later, and the same strategy can also be applied to checking if the span/log will be sampled out or if instrumentation is currently suppressed.logfire.instrument_<module>
will also apply instrumentation including patching, but (1) that's necessary to allow callingconfigure
later and having it all just work and (2) that's how OTEL works anyway.