Add logfire-api

[Kludex]

This PR creates the logfire-api package.

We'll have to remove rye - or it needs to work with editable mode, otherwise developers need to remember to remove the .venv and run rye sync --no-lock every time they perform changes.

The approach here is simple - the logfire-api/logfire_api/__init__.py contains all the runtime logic, and the type hints are generated from the make generate-stubs command - we have a lot of pyi files.

There are two tests:

1. One that makes sure both logfire and logfire_api have the same objects in the __init__.py.
2. Another that makes sure we have the __init__.pyi type compliant.

[cloudflare-pages]

Deploying logfire-docs with    Cloudflare Pages

Latest commit:	8f42fe8
Status:	✅  Deploy successful!
Preview URL:	https://c57b71f1.logfire-docs.pages.dev
Branch Preview URL:	https://logfire-api.logfire-docs.pages.dev

View logs

[samuelcolvin]

You need to add methods like span() which return something functionally consistent with logfire.span().

And also.

def __getattr__(self, attr):
    return MagicMock()

We perhaps we shoud also implement all the know methods with a signature of (*args, **kwargs) -> None, then leave this as a fallback.

[adriangb]

Returning a MagicMock outside of tests seems bad IMO. Can we follow the opentelemetry-api way of doing this?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[Kludex]

@alexmojaki do you know why those tests are failing? 🤔 There are different tests failing depending on the Python version...

[Kludex]

I've created the publisher... Not sure if this works.

[alexmojaki]

I don't know why. How new/consistent are they?

[samuelcolvin]

This looks awesome.

Thank you!

[adriangb]

It seems like the idea is to generate stubs / API files from all of logfire. IMO this is unnecessary. The use case for a logfire-api is that libraries can instrument with logfire without depending on requests, etc. I think all that's needed is logfire.span(...), logfire.info(...) and maybe the things those return. It can just be something like this:

try:
    import logfire
except ImportError:
   logfire = None

def info(...) -> None:
    if logfire:
       logfire.info(...)
 
def span(...) -> ?:
    if logfire:
        return logfire.span(...)
    return ?

I leave ? as "not sure what we should return for LogfireSpan. Maybe we implement a LogfireSpanApi and have LogfireSpan inherit from it? I also think we should audit what methods/attributes are on LogfireSpan. E.g. if it gives you access to the underlaying opentelemetry.sdk.Span it maybe should be switched to opentelemetry.Span.

[Kludex]

It seems like the idea is to generate stubs / API files from all of logfire. IMO this is unnecessary.

Since it's automated, I don't see the issue.

I think all that's needed is logfire.span(...), logfire.info(...) and maybe the things those return.

This was already discussed. Also, it was the first question before I started implementing it.

It can just be something like this:

If it were few objects, yes... But for every object on logfire/__init__.py, the current logic is easy to maintain because you don't need to add the conditionals on every logfire_api object.

[adriangb]

My point is that libraries instrumenting with logfire don't need e.g. logfire.instrument_fastapi().

[alexmojaki]

My point is that libraries instrumenting with logfire don't need e.g. logfire.instrument_fastapi().

See https://github.com/search?q=repo%3AMirascope%2Fmirascope%20instrument_openai&type=code

[samuelcolvin]

Let's go ahead with this, I don't really see the point of putting effort into limiting the type hint coverage.

Let's go ahead with this.

@adriangb we have to make some decisions on calls without the whole team present, if you don't join calls you have to accept some decisions are made without you.

[Kludex]

@alexmojaki Anything else, or can I merge? I've applied all your comments.

[alexmojaki]

Thanks!