Split into backend-agnostic core + per-backend serving packages

[mtelvers]

Recording and collection no longer depend on a concurrency library, so metric-defining libraries depend only on prometheus; an application chooses Lwt or Eio only when it serves metrics.

• prometheus (core): Lwt-free, direct-style. CollectorRegistry.collect returns a plain snapshot; a collector may perform I/O via effects, handled by whatever scheduler runs collect.
• prometheus-app: backend-free text-format renderer + GC collectors (no cohttp, no concurrency library).
• prometheus-cohttp: a /metrics handler functor over cohttp's Cohttp.Generic.Server.S, usable with any cohttp backend.
• prometheus-lwt (+ .unix): Lwt collectors (register_lwt), an Lwt collect that merges the core's synchronous metrics, Lwt timing helpers, and the cohttp-lwt server + cmdliner + logging.
• prometheus-eio: direct-style timing helpers and a cohttp-eio handler; async collection needs no special machinery under Eio.

Tests cover the core (incl. an effects-driven collector), the Lwt sync+async merge, and the Eio path under Eio_main. README updated.

Replaces #59.

[dinosaure]

I'm not sure if it's right to just delete the Lwt.t, the trick is to define a type 'a io and specify it as type 'a io = 'a Lwt.t for lwt and type 'a t = 'a for something like eio.

[talex5]

It think we can we just drop OCaml 4 support for new versions of prometheus now. As long as we have a compiler with support for effects, we can still implement Lwt support even if the core library is direct style.

[dinosaure]

I'm not sure to follow you, the main aim is to keep Lwt.t as it is (that doesn’t have much to do with the effects and OCaml 4/5).

[mtelvers]

@dinosaure, Lwt.t is preserved, just in Prometheus_lwt.CollectorRegistry rather than in the core. The Lwt-facing surface in lwt/prometheus_lwt.mli is the same shape as v1.2's register_lwt / register_pre_collect_lwt / collect : t -> snapshot Lwt.t, so Lwt applications keep the semantics they had.

The choice was: (a) parameterise the core over 'a io (your Make(IO) shape) so a single library serves both backends, or (b) make the core direct-style and ship a small Lwt wrapper that re-introduces the Lwt.t surface for Lwt callers.

This PR goes with (b) because recording (Counter.inc, Gauge.set, Histogram.observe) is genuinely synchronous and doesn't want to flow through 'a io. Under (a), library authors who only define and increment metrics still see the abstraction. Under (b), they don't. Eio also drops out for free: a collector that needs to suspend just performs IO via effects, no Make(IO_eio) needed.

The runtime behaviour and the visible Lwt API are identical between (a) and (b); the difference is which side of the library carries the abstraction. The current shape gives both groups what they need: library authors a scheduler-free core, Lwt apps an unchanged Lwt.t API, Eio apps a direct-style one.

[dinosaure]

Hmmhmm, sorry I need more time to review and see the implication of such change in the context of lwt.

[avsm]

I took a look at this patch, and I think that the Lwt type isn't necessary in the core since Prometheus doesn't actually need to block in normal use as it's updating a scoreboard (like incrementing an int or other counter).

However, it would be far easier to review if the PR were split up into two: one that only moves the Lwt logic out of the core, and then a subsequent set of PRs that add eio, miou and whatever other backends people want. Having just the Lwt moving out of the core will be the interface breaking one for most existing users, so I'd like to release that separately of any new features. @mtelvers has agreed to have a go at this; thanks Mark!

[avsm]

@mtelvers I also think #56 looks relevant to the refactoring

[dinosaure]

Ok let's move, I lost my energy when I saw the force-push during my review but globally, it seems good for me.