Packaging discussion

[Konrad `ktoso` Malawski]

So with the @_exports gone, the following is not true anymore right?

import PrometheusMetrics // Auto imports Prometheus too, but adds the swift-metrics compatibility

?

[Konrad `ktoso` Malawski]

I'm wondering if there is a reason to have the two in separate modules really btw...
Does not really cost much to have just Prometheus and it also implement the Metrics it is "shared currency" API after all, wdyt @weissi

// Finding those as I'm trying to use it today btw :-)

[Jari (LotU)]

Fixed in 31d6964. Though I'm still not sure how to handle this. I know for a fact that Vapor uses @_exported a lot. I also think that in this specific usecase, it doesn't have many of the drawbacks it normally gives you.

The reason I separated the two is because I don't want to pressure people into using the swift-metrics APIs because in my case, the standalone Prometheus APIs give you more power.

Curious to hear input on this though. CC @weissi

[Johannes Weiss]

Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).

Regarding the @_exported import: What exactly are the things that you would need to have exported? I thought unless you're a special prometheus power-user you'd just live off the API that SwiftMetrics gives you?

So what I was thinking (please correct me if I'm wrong), you'd do in your main.swift

import Metrics
import PrometheusMetrics

PrometheusMetrics.bootstrap(....)

but in all other files, you'd just do

import Metrics

// use the metrics

So rephrasing the question: If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus?

[Konrad `ktoso` Malawski]

Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).

There seems to be a misunderstanding here I think?

It can be:

• 1 module
• swift-metrics handler implementations
• the PromCounter et al types
• users pick whichever they

And users should:

• use the powerful apis if they want, sure!
• do bootstrap the

If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus?

There is no one "normal case" I'd argue, there are two:

• a library; never even has access to Prometheus -- uses SwiftMetrics
• an end user app:
  • should bootstrap PrometheusMetrics.bootstrap(....)
  • MAY want to use the PromGauge types in some places, since e.g. it provides add/sub which SwiftMetrics does not ( apple/swift-metrics#36 ), or similar "has more features" cases
  • in other places is totally fine with plain Counter etc, since those sources are then maybe easier to rip into mini libraries etc etc.

[Johannes Weiss]

Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).

There seems to be a misunderstanding here I think?

It can be:

• 1 module
• swift-metrics handler implementations
• the PromCounter et al types
• users pick whichever they

And users should:

• use the powerful apis if they want, sure!
• do bootstrap the

If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus?

There is no one "normal case" I'd argue, there are two:

• a library; never even has access to Prometheus -- uses SwiftMetrics

• an end user app:

  • should bootstrap PrometheusMetrics.bootstrap(....)
  • MAY want to use the PromGauge types in some places, since e.g. it provides add/sub which SwiftMetrics does not ( apple/swift-metrics#36 ), or similar "has more features" cases
  • in other places is totally fine with plain Counter etc, since those sources are then maybe easier to rip into mini libraries etc etc.

@ktoso Yes, you're totally right, agree with you. I was worried about the 'pollution' of the namespace by having both the Prometheus APIs as well as the 'Prometheus for SwiftMetrics boostrapping' bits imported. However I think that concern is mostly moot because there are two cases:

1. user uses the SwiftLog API (the "normal" case): apart from one file (where they bootstrap), they only ever import Metrics, so they wouldn't see the direct Prometheus APIs
2. they are a power Prometheus user and use the Prometheus APIs directly: The pollution is restricted to just one function (the Prometheus.bootstrap function) which is acceptable.

So in both cases, the pollution is minimal: In case (1) it's restricted to one file and in (2) it's just one function. So in hindsight I think this should just be one module.

[Joe Smith]

Gave this a whirl at #9, if someone's already working on this I'm happy to defer to that!

[Jari (LotU)]

Awesome work on #9 ! I left a review there. @ktoso @weissi I would greatly appreciate if the two of you could also give it a quick look 😄