Adding opentelemetry-distro package and entrypoint

[codeboten]

Description

As per the discussion in the SIG meeting on 12/03, providing an entrypoint that is loaded before the configurator would reduce the amount of work needed by users in creating distro's for otel python. This PR proposes that change by introducing an opentelemetry_distro entrypoint, as well as a distro that configures the OTLP exporter by default.

Fixes #1481

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[lzchen]

Do we still need this?

[codeboten]

this is changing the default in the SDK configurator not to make a decision for users as to what exporter to configure

[lzchen]

Why not remove the line completely?

[codeboten]

Removed.

[lzchen]

Curious what is the execution order of things in sitecustomize.py? Is it always run first? If users were to auto-instrument using one of the console scripts, do the scripts run first or sitecustomize.py?

[ocelotl]

I think the nomenclature here is a bit confusing. We have a Distro class that does configuration. Actually, what we have here is not only a way to perform configuration but a hook that allows users to register some code to be executed before the instrumentors are executed, right?

I don't want to over-generalize this, but maybe users will also need to run stuff after the instrumentors? Is this an opportunity to provide a more general-purpose hook mechanism? I understand if you don't want to spend much time in these abstract design or philosophical questions, just mentioning this just in case this brings in you any valuable idea.

Any way, I believe the Distro name is not very appropriate, maybe something more precise like BeforeInstrumentors would fit better? 🤷‍♂️

[lzchen]

This is the default Opentelemetry distro right? What would other distros be called?
azure = opentelemetry.distro:AzureDistro something like this?

[codeboten]

i'd originally called it otel_distro, but based on @ocelotl's feedback changed it to distro. I don't feel strongly one way or the other on this. I would expect the distro to match the vendor, as you suggested, azure would identify the Azure distro. in that case maybe this would make more sense as otel

[lzchen]

I personally think it's best to prefix everything with an "opentelemetry" identifier just in case there are other libraries using a similar name within the entry points.

[lzchen]

@ocelotl
I think the purpose of distros is to run vendor specific logic before instantiation. I'm not sure if there will be the existence of after hooks so this is most likely a different concept than that. Regardless, distro is a commonly used term to describe something like this, see Java

[lzchen]

Nice. Just one non-blocking comment.

[codeboten]

@ocelotl: The term distro was proposed in a few different SIG meetings (maintainers and spec meetings that i know of), it's a concept that is already being promoted both in the opentelemetry community and by vendors.

This PR is moving code that was doing some default configuration out of the SDK and into a distro that can be used as-is by users. This also serves as an example for how others could implement their own distro, with whatever defaults makes sense for them.

[ocelotl]

@ocelotl: The term distro was proposed in a few different SIG meetings (maintainers and spec meetings that i know of), it's a concept that is already being promoted both in the opentelemetry community and by vendors.

This PR is moving code that was doing some default configuration out of the SDK and into a distro that can be used as-is by users. This also serves as an example for how others could implement their own distro, with whatever defaults makes sense for them.

Ok, sounds good 👍 Approving 😎