Should we introduce a pkg module directory?

[dmitryax]

We already have 17 root directories for modules with exported API. It's a pretty long list which can be hard to navigate. Some of them are important and reflect the collector's configuration interfaces in some way, e.g. exporter, receiver, processor, connector, extension, service. Some other directories are pretty small and serve a specific purpose, e.g.: client, semconv, confmap.

Currently, we have a need to introduce another utilitarian module that probably shouldn't be at the root level: filter. See #9660 (comment).

Should we introduce pkg directory in this repo similar to https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg and put the new filter module there?

We can probably keep pdata and featuregate at the root level since they reached 1.x along with exporter, receiver, processor, connector, extension, service, but can consider moving other modules like client, semconv, confmap to pkg as well.

[mx-psi]

What would be the criteria to have something be in pkg or not? I am also not sure what problem are we trying to solve. Is it mostly not knowing where to put filter, or is there more to it?

Personally, I don't like pkg on contrib, so I wouldn't want to introduce it here 😄 I also don't think we should change the import path of a bunch of modules if we don't have a very good reason to do it.

[jpkrohling]

Most of the things we have in core are libraries, so I wouldn't group them under pkg.

For contrib, I can see the reason: most of the things there are components, and grouping the libraries used by then under pkg can help make them discoverable.

[dmitryax]

Is it mostly not knowing where to put filter, or is there more to it?

Mostly, yes. filter on the root level might sound confusing.

[dmitryax]

For contrib, I can see the reason: most of the things there are components, and grouping the libraries used by then under pkg can help make them discoverable.

It's also the case for core, where we have the component directories that would be better to highlight in some way.

[dmitryax]

I'm okay with going without pkg as well. I'll close the issue if no one else sees it beneficial.

[TylerHelmuth]

Agree on not adding pkg. In Contrib it feels like pkg is a place to put reusable public modules in a repo with a lot of public modules (via the components) that shouldnt be depended on. But in Core a majority of the public modules already have the expectation to be use directly.

[codeboten]

Happy to continue w/o a pkg folder as well.

[dmitryax]

Closing based on the feedback