-
Notifications
You must be signed in to change notification settings - Fork 657
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
Contrib package naming convention #283
Comments
Maybe this can be solved automatically by moving all the Also, if this is done, would it be a good idea to define base classes for every kind of contrib package? If that is done, and if the contrib packages are turned into standard Python plugins that register themselves through entry points, then these base classes can be used to check for plugin sanity while they are being registered. For example, exporters can be checked so that they comply with the minimal exporter implementation, and that they return the right types, etc. Also, the contrib packages could be named after their kind, for example: |
Here's a PR with some conventions: open-telemetry/opentelemetry-specification#539
|
@toumorokoshi |
I would argue they should follow the convention of the primary repos as well, but obviously there's no enforcement there. :) |
Closing in favour or #760 |
We've been naming contrib packages (integrations, exporters, plugins, etc.)
opentelemetry-ext-foo
and keeping them in theext/
dir.There are two exceptions to this: In #272 @lzchen changed the azure monitor exporter package name from
opentelemetry-ext-azure-monitor
toopentelemetry-azure-monitor-exporter
, and the opentracing shim was namedopentelemetry-opentracing-shim
in #271.Do we want to stick with the
ext
naming convention for packages only as long as their source lives in the main repo? Should we use different conventions for different kinds of contrib packages?One nice feature of the
opentelemetry-ext-foo
convention is that it matches the import path,opentelemetry.ext.foo
. It also makes it easy to search for these packages by name. One problem is that "ext" is ambiguous, and doesn't capture the differences between different kinds of contrib packages: exporters that extendopentelemetry-python
to work with different APMs, integrations that wrap existing libraries to generate telemetry data using the OT API, etc.The text was updated successfully, but these errors were encountered: