Skip to content
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

Closed
c24t opened this issue Nov 11, 2019 · 5 comments
Closed

Contrib package naming convention #283

c24t opened this issue Nov 11, 2019 · 5 comments

Comments

@c24t
Copy link
Member

c24t commented Nov 11, 2019

We've been naming contrib packages (integrations, exporters, plugins, etc.) opentelemetry-ext-foo and keeping them in the ext/ dir.

There are two exceptions to this: In #272 @lzchen changed the azure monitor exporter package name from opentelemetry-ext-azure-monitor to opentelemetry-azure-monitor-exporter, and the opentracing shim was named opentelemetry-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 extend opentelemetry-python to work with different APMs, integrations that wrap existing libraries to generate telemetry data using the OT API, etc.

@ocelotl
Copy link
Contributor

ocelotl commented Nov 12, 2019

Maybe this can be solved automatically by moving all the ext directories into their own individual repo?

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: opentelemetry-foo-exporter or opentelemetry-foo-integrator.

@toumorokoshi
Copy link
Member

Here's a PR with some conventions:

open-telemetry/opentelemetry-specification#539

opentelemetry-instrumentation-redis
opentelemetry-exporter-jaeger

@lzchen
Copy link
Contributor

lzchen commented Apr 27, 2020

@toumorokoshi
Just curious, these normalized terms are only for packages in the main OT repos right? Vendors are still free to name their exporters whatever they like?

@toumorokoshi
Copy link
Member

I would argue they should follow the convention of the primary repos as well, but obviously there's no enforcement there. :)

@codeboten
Copy link
Contributor

Closing in favour or #760

srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this issue Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants