Move apis package to a dedicated sub-module

[iypetrov]

Description:
The goal of this PR is to separate the apis package from the core operator module, allowing other projects to use its structs without pulling in the operator’s full set of indirect dependencies.

Link to tracking Issue(s):
#4362

• Resolves: APIs package should not import github.com/goccy/go-yaml #4362

Testing:
No new tests are added, just adapt some of the existing ones.

Documentation:
Should be added.

[iypetrov]

@swiatekm are you okay with removing the github.com/goccy/go-yaml dependency from just the apis sub-module and using the standard library instead in this case?

[pavolloffay]

@iypetrov It would be cleaner to first only migrate the yaml package and then do the API package separation.

[pavolloffay]

 gopkg.in/yaml.v3 is actually used elsewhere in this project. The apis/ package specifically uses goccy/go-yaml for these features that yaml.v3 lacks:
                                                                                                                                                                                                                                                                                                         
  1. IndentSequence(true) - Controls sequence indentation separately from map indentation. In yaml.v3, sequences always use a fixed style.                                                                                                                                                               
  2. AutoInt() - Converts 1.0 ? 1 in output. Cleaner collector configs without floating point artifacts.
  3. YAMLToJSON() / JSONToYAML() - Built-in conversion functions. The API package needs both formats (JSON for Kubernetes API, YAML for collector config display).                                                                                                                                       
                                                                                                                                                                                                                                                                                                         
  yaml.v3 has a more limited encoder API - you can set Indent but can't control these specific behaviors. For the collector config output (which users see and may copy), the formatting precision matters.                                                                                              
                                                                                                                                                                                                                                                                                                         
  The rest of the codebase uses yaml.v2 for simpler marshal/unmarshal where output formatting isn't user-facing.

[iypetrov]

 gopkg.in/yaml.v3 is actually used elsewhere in this project. The apis/ package specifically uses goccy/go-yaml for these features that yaml.v3 lacks:
                                                                                                                                                                                                                                                                                                         
  1. IndentSequence(true) - Controls sequence indentation separately from map indentation. In yaml.v3, sequences always use a fixed style.                                                                                                                                                               
  2. AutoInt() - Converts 1.0 ? 1 in output. Cleaner collector configs without floating point artifacts.
  3. YAMLToJSON() / JSONToYAML() - Built-in conversion functions. The API package needs both formats (JSON for Kubernetes API, YAML for collector config display).                                                                                                                                       
                                                                                                                                                                                                                                                                                                         
  yaml.v3 has a more limited encoder API - you can set Indent but can't control these specific behaviors. For the collector config output (which users see and may copy), the formatting precision matters.                                                                                              
                                                                                                                                                                                                                                                                                                         
  The rest of the codebase uses yaml.v2 for simpler marshal/unmarshal where output formatting isn't user-facing.

So based on this there is no need to first migrate the yaml package , because it is mandatory in this case?

[pavolloffay]

I haven't verified if the yaml.v3 can't really do it. Maybe there is a workaround that the AI could not figure out

[iypetrov]

Okay, I'll check it on my side and if I find it could, I'll create a dedicated PR for that. Thanks for the comment!

[iypetrov]

I made a little research and I realized there was a misunderstanding on my side. My original goal was to avoid using third-party packages in the apis sub-module. However, since Go doesn’t provide YAML encoding in the standard library, using a library like gopkg.in/yaml or goccy/go-yaml is unavoidable. IMO no changes are required in this case.

[swiatekm]

Looking at this PR, I think I'd prefer to start by moving all the code that the API structs don't depend on into ./internal. This would include config parsing and CRD metrics. Ideally, the PR adding the new module shouldn't change anything other than import paths and go.mod files.

[iypetrov]

Looking at this PR, I think I'd prefer to start by moving all the code that the API structs don't depend on into ./internal. This would include config parsing and CRD metrics. Ideally, the PR adding the new module shouldn't change anything other than import paths and go.mod files.

In internal/apihelpers, right?

[swiatekm]

Looking at this PR, I think I'd prefer to start by moving all the code that the API structs don't depend on into ./internal. This would include config parsing and CRD metrics. Ideally, the PR adding the new module shouldn't change anything other than import paths and go.mod files.

In internal/apihelpers, right?

Sure, though it doesn't need to be called that. I'd accept internal/otelconfig and internal/metrics.