Comments (9)
You can have multiple modules in the same repo, but it takes careful consideration: https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories.
To date I don't understand what is meant by "API" and "SDK", but I feel like those should maybe be in the same place. If they are in the same place, what would be outside?
from opentelemetry-go.
To date I don't understand what is meant by "API" and "SDK", but I feel like those should maybe be in the same place. If they are in the same place, what would be outsid
@freeformz this should help https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/library-guidelines.md
from opentelemetry-go.
My understanding is that having separate modules for API and SDK is desirable in the situation when the SDK has a lot more dependencies than the API and you do not want all those dependencies to pollute the end-user application if they only import the API.
Question: how much of a problem is this? Isn't Go compiler smart enough not to link with any of the dependencies referenced in go.mod of the module but otherwise unused (not imported) by the end-user application?
Are there any other downsides to placing API and SDK in the same module (but obviously in different packages)?
from opentelemetry-go.
@tigrannajaryan Thanks for that link, yes that helps, although the motivations for the separation of API and SDK are still a little too abstract for my liking.
For instance I can write (and have written) a package (or set of packages) that provides an API for users AND for others to provide protocol independent functionality for the purposes of enriching the standard data and exporting it to services.
WRT single vs multiple repos though, what is the motivation for this? Where is that documented?
from opentelemetry-go.
Thanks for that link, yes that helps, although the motivations for the separation of API and SDK are still a little too abstract for my liking.
For me the primary motivation is ability to use libraries instrumented with OpenTelemetry without enabling telemetry delivery (or as a third-party library author not being required to maintain instrumented and non-instrumented versions of my lib). That's pretty specific in my opinion. Other reasons are listed in the linked doc, and probably different people have different opinions about what is the primary motivation.
If you can think of a better way to achieve the goals stated in the doc please feel free to suggest a different approach.
For instance I can write (and have written) a package (or set of packages) that provides an API for users AND for others to provide protocol independent functionality for the purposes of enriching the standard data and exporting it to services.
I do not quite understand what this means and how it relates to the subject matter, please clarify.
WRT single vs multiple repos though, what is the motivation for this? Where is that documented?
I am likely not the best person to answer this question, I am not aware of any discussions or docs in OpenTelemetry on this topic. Today's SIG meeting is the first time I was exposed to the issue in the context of OpenTelemetry project.
from opentelemetry-go.
WRT single vs multiple repos though, what is the motivation for this? Where is that documented?
The problem (if there is one) is specific to Go. In Java, you can build many packages from same repo and you could potentially depend on different version for different package. For example, you could have dependency on
- api-0.1.0.jar
- sdk-0.1.9.jar
OR one could have dependency only on api but not sdk
- api-0.1.0.jar
- private-sdk-0.1.2.jar (custom sdk or third party sdk).
In Go, would that be possible with one repo?
In Go,
from opentelemetry-go.
@tigrannajaryan A library needs to declare it's dependencies and let it's users determine how to configure them. So if I write a library that is instrumented with OpenTelemetry I need to expose a way for the user of the library to attach an exporter, sampler, etc. I'm asking other questions in the specification gitter, because the wording in the spec (the doc you linked) seems kind of nuts to me. So I'm obviously missing something.
@rghetia Yes, but see my link above about multiple modules in a single repo.
In Go....
A repo can contain one or more modules.
Modules are a collection of packages.
Modules are versioned packages aren't.
A module can require multiple major versions of another module, but those are resolved to only a single version of each major module version. Ex: api @ v1.0.12 (import api
) and api @ v2.0.5 (import api/v2
)
So, AFAICT it would be possible to do what you are saying with:
(a) A single repo and a single module that contains two packages (api & sdk). (ot/ot-go/api, ot/ot-go/sdk, ot/ot-go/v2/api, ot/ot-go/v2/sdk, etc);
(b) a single repo with 2 modules (ot/ot-go/sdk, ot/ot-go/api, ot/ot-go/sdk/v2, ot/ot-go/api/v2, etc)
(c) two repos, each with their own module (ot/ot-go-sdk, ot/ot-go-api, ot/ot-go-sdk/v2, ot/ot-go-api/v2).
(a) ties all releases to the same tags. So when v1.0.1 is tagged it applies to both api & sdk. This can be a good thing or a bad thing depending on your constraints.
(b) allows for tagging api and sdk separately: Ex: api/v1.0.1
and sdk/v1.0.0
. But there are some other things to consider for using / testing / etc that are mentioned in the module's wiki. Most importantly it may be necessary to use replace
in some development situations, which I don't have a great handle on.
(c) Since api and sdk would be in their own repos, each can be tagged / released separately using unprefixed tags as normal.
from opentelemetry-go.
@rghetia Yes, but see my link above about multiple modules in a single repo.
For some reason, I missed that. Thanks for the link. It is clear. We can start with 'a' and change it to 'b' if necessary.
from opentelemetry-go.
current directory structure seems good.
from opentelemetry-go.
Related Issues (20)
- Move from build-tools to weaver HOT 1
- Audit Compliance: Logs Bridge API Logger Provider
- Audit Compliance: Logs Bridge API Logger
- Audit Compliance: Logs Bridge API Concurrency Requirements
- Audit Compliance: Logs Bridge API Artifact Naming
- Audit Compliance: Logs Bridge SDK Logger Provider
- Audit Compliance: Logs Bridge SDK Logger
- Audit Compliance: Logs Bridge SDK ReadableLogRecord HOT 1
- Audit Compliance: Logs Bridge SDK ReadWriteLogRecord HOT 1
- Audit Compliance: Logs Bridge SDK LogRecord Limits
- Audit Compliance: Logs Bridge SDK LogRecordProcessor Interface
- Audit Compliance: Logs Bridge SDK Bult-in LogRecord Processors
- Audit Compliance: Logs Bridge SDK Log Record Exporter
- Audit Compliance: Logs Bridge No-Op Implementation
- SetAttributes/AddAttributes truncate strings down to 0-length HOT 5
- log: Add noCmp fields
- Update the no-op trace implementations to support auto-instrumentation
- How to Ignore `context.Canceled` Error HOT 1
- Otlp: `too many colons in address` when export env: `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` HOT 4
- [new feature] metrics: support prometheus remote write exporter. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opentelemetry-go.