Closed MrLotU closed 4 years ago
I think this is a good idea and in fact as mentioned in #130 it is fairly simple to achieve. The build-time dependency can already be removed just by splitting the library product into two in Package.swift
. If you also split the repository, users of SwiftMetrics
will not need to download all of Kitura.
I have a suggestion we can create Two Different Packages with two different Repositories like this,
Package.swift
import PackageDescription
let package = Package(
name: "SwiftMetricsCore",
products: [
.library(
name: "SwiftMetricsCore",
targets: ["SwiftMetricsCore"
]),
],
dependencies: [
.package(url: "https://github.com/IBM-Swift/SwiftyRequest.git", from: "1.0.0"),
.package(url: "https://github.com/IBM-Swift/Swift-cfenv.git", from: "6.0.0"),
.package(url: "https://github.com/RuntimeTools/omr-agentcore", .exact("3.2.4-swift4")),
],
targets: [
.target(name: "SwiftMetricsCore", dependencies: ["agentcore", "hcapiplugin", "envplugin", "cpuplugin", "memplugin", "CloudFoundryEnv"]),
]
)
Package.swift
import PackageDescription
import Foundation
var webSocketPackage: Package.Dependency
if ProcessInfo.processInfo.environment["KITURA_NIO"] != nil {
webSocketPackage = .package(url: "https://github.com/IBM-Swift/Kitura-WebSocket.git", .exact("0.1.0-nio"))
} else {
webSocketPackage = .package(url: "https://github.com/IBM-Swift/Kitura-WebSocket.git", from: "2.0.0")
}
let package = Package(
name: "SwiftMetrics",
products: [
.library(
name: "SwiftMetrics",
targets: [
"SwiftMetricsKitura",
"SwiftBAMDC",
"SwiftMetricsBluemix",
"SwiftMetricsDash",
"SwiftMetricsREST",
"SwiftMetricsPrometheus"]),
.executable(name: "SwiftMetricsEmitSample", targets: ["SwiftMetricsEmitSample"]),
.executable(name: "SwiftMetricsCommonSample", targets: ["SwiftMetricsCommonSample"]),
],
dependencies: [
.package(url: "https://github.com/RuntimeTools/SwiftMetricsCore", from: "1.0.0"),
.package(url: "https://github.com/IBM-Swift/Kitura.git", from: "2.3.0"),
webSocketPackage,
.package(url: "https://github.com/IBM-Swift/Swift-cfenv.git", from: "6.0.0"),
.package(url: "https://github.com/RuntimeTools/omr-agentcore", .exact("3.2.4-swift4")),
],
targets: [
.target(name: "SwiftMetricsKitura", dependencies: ["SwiftMetricsCore", "Kitura"]),
.target(name: "SwiftBAMDC", dependencies: ["SwiftMetricsKitura", "Kitura-WebSocket"]),
.target(name: "SwiftMetricsBluemix", dependencies: ["SwiftMetricsKitura","SwiftBAMDC"]),
.target(name: "SwiftMetricsDash", dependencies: ["SwiftMetricsBluemix"]),
.target(name: "SwiftMetricsREST", dependencies: ["SwiftMetricsKitura"]),
.target(name: "SwiftMetricsPrometheus", dependencies:["SwiftMetricsKitura"]),
.target(name: "SwiftMetricsCommonSample", dependencies: ["SwiftMetricsCore"],
path: "commonSample/Sources"),
.target(name: "SwiftMetricsEmitSample", dependencies: ["SwiftMetricsCore"],
path: "emitSample/Sources"),
.testTarget(name: "CoreSwiftMetricsTests", dependencies: ["SwiftMetricsCore"]),
.testTarget(name: "SwiftMetricsRESTTests", dependencies: ["SwiftMetricsREST"])
]
)
Any new update on this?
Any progress? Can we help move this forward?
I'm afraid we (IBM) aren't able to devote engineering resources towards this at the moment. Of course that may change in future. We have no objections to doing this though.
@ianpartridge I was suggesting for us (the community) to move this forward @satishbabariya @MrLotU do you have a working setup that you can PR?
@ianpartridge What we potentially could do is move the system metrics part of this lib to a separate thing and propose it to the SSWG, maybe for apple itself to adopt even? If not, I can create a new repo with the lowerlevel things, and PR this repo to depend on that one. If IBM is ok with it, you could of course adopt that on a later point than 😄
On a high level, anything wrong with that?
Hi @MrLotU you are very welcome to use anything from this repo that's useful to you - it's ASLv2 licensed so nice and friendly :) I know of other people who have forked and used bits that they wanted. We probably wouldn't change this repo to depend on a 3rd-party repo because SwiftMetrics is in the package graph of most Kitura applications.
There is a metrics API under review at https://forums.swift.org/t/feedback-server-metrics-api/21353/12 - we may well enhance SwiftMetrics to be compliant with that in future. As you say, pieces could contribute into that effort if appropriate.
This is currently also being tackled in https://github.com/apple/swift-metrics/issues/53
Right now, SwiftMetrics as a Package, has a dependency on Kitura, although for the core module
SwiftMetrics
, this is not the case. This makes it really annoying and costly to integrate in non Kitura projects, for example my own VaporMonitoring which is based on this package.My proposal here, is to split this package up into 2.
SwiftMetrics
, providing what theSwiftMetrics
core package provides, andSwiftMetricsKitura
or something of the likes, providing the Kitura specific implementations, just as how I createdVaporMonitoring
.