Skip to content
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

Merged
merged 7 commits into from
May 31, 2024
Merged

Don't configure automatically #219

merged 7 commits into from
May 31, 2024

Conversation

alexmojaki
Copy link
Contributor

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 making logfire.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 calling configure later and having it all just work and (2) that's how OTEL works anyway.

Copy link

codecov bot commented May 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

@alexmojaki alexmojaki requested a review from adriangb May 28, 2024 19:06
Copy link
Member

@samuelcolvin samuelcolvin left a 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):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be public?

Copy link
Contributor Author

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.

@alexmojaki
Copy link
Contributor Author

I just want to confirm that none of the behaviour actually changes with this 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.

Copy link

cloudflare-workers-and-pages bot commented May 30, 2024

Deploying logfire-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 172a742
Status: ✅  Deploy successful!
Preview URL: https://d34b3a64.logfire-docs.pages.dev
Branch Preview URL: https://alex-no-auto-configure.logfire-docs.pages.dev

View logs

@alexmojaki alexmojaki enabled auto-merge (squash) May 31, 2024 13:07
@alexmojaki alexmojaki merged commit d27759f into main May 31, 2024
10 checks passed
@alexmojaki alexmojaki deleted the alex/no-auto-configure branch May 31, 2024 13:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't configure automatically
2 participants