-
Notifications
You must be signed in to change notification settings - Fork 825
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
Make package structure more consistent #408
Comments
Mapping between old package name to new name.
|
I wonder if we even need
and the reason is that we already have a word |
I am trying to imagine what using the final product is going to look and feel like to end users. In my mind there are a few types of users:
They have different uses for packages and will need to use different packages to fulfill those needs. I would describe app owners as consuming OpenTracing, lib and plugin devs as developing software using OpenTelemetry, and core devs as building OpenTelemetry. I would typically think of "Library X SDK" as a tool for developing software that interacts with "Library X", not simply a consumer. As an example think of the jdk vs jre. The jdk is used to develop java programs, but if you just need to run one you only need the jre. With these things in mind I would propose the following names:
|
Do we want more fine grained package naming for web code to reduce bundled code size? That way if someone is using only the metrics implementation, they don't have to also import the tracer code. |
As mentioned, this can be done as needed. We won't publish metrics with the alpha so we can decide as we build out metrics. |
I tend to agree with @obecny. The entire repo is basically the SDK, no need to specify that at every package really. |
I think there should be more fine-grained packages, but there should still be the aggregate that is bigger but easier to install to get started. |
Triggered by #389 @mayurkale22 and I started a discussion on the overall consistency of our package naming and we came up with the following scheme:
@opentelemetry/sdk-base @opentelemetry/sdk-tracing (basic tracer - mainly for manual operations) @opentelemetry/sdk-metrics @opentelemetry/sdk-node (sdk-base + sdk-tracing + sdk-metrics) @opentelemetry/sdk-web (sdk-base + sdk-tracing + sdk-metrics)
@opentelemetry/sdk-metrics
can later be appended by a platform if we need a specialization which would lead to@opentelemetry/sdk-metrics-node
and@opentelemetry/sdk-metrics-web
Linking the very first discussion on naming #6 for backreference.
Please add your thoughts as this needs to be done before we can cut the release.
The text was updated successfully, but these errors were encountered: