[RFE] Split go-commons in different modules

[rsevilla87]

At the moment go-commons is an all-in-one module, this is coming with several caveats.

• Cutting a new release affects all the libraries, this is not desired since a project could want to stick on an specific release of a library.

• Creates too many dependencies, a project only using one of the libraries will inherit all go-commons dependencies.

Splitting the project in different modules comes also with some downsides, the versioning handling of the different modules will be the most problematic one.

Let's use this issue to discuss about the possibilities

[vishnuchalla]

At the moment go-commons is an all-in-one module, this is coming with several caveats.

• Cutting a new release affects all the libraries, this is not desired since a project could want to stick on an specific release of a library.

Yes we can manage the version of the package in a go.mod file. So, the downstream will not see any breaking changes until unless they make changes to their dependency version.

• Creates too many dependencies, a project only using one of the libraries will inherit all go-commons dependencies.

IMHO, go vendoring only inherits the packages that are used as import statements in a project. For example clair-load-test only uses this import statement github.com/cloud-bulldozer/go-commons/indexers and we only have indexers package downloaded in the vendor files and used in building a binary. No other packages are downloaded.

├── github.com
│   ├── cloud-bulldozer
│   │   └── go-commons
│   │       └── indexers
│   │           ├── elastic.go
│   │           ├── factory.go
│   │           ├── local.go
│   │           ├── opensearch.go
│   │           └── types.go

Splitting the project in different modules comes also with some downsides, the versioning handling of the different modules will be the most problematic one.

Correct me if I am wrong, I don't think this is required. From the answer to the above question, as the downstream only inherits the imported package, changes in other packages should not affect them.

Let's use this issue to discuss about the possibilities

Inline answers for the above questions.

[vishnuchalla]

I believe, a good solution for this problem would be to have unit tests written for this library with > 90% of coverage. That should help us to mitigate most of the issues in development phase itself. Open to other thoughts too. Thank you!

[chentex]

Regarding multiple modules, getting the configuration for each of them should not be a problem, the biggest issue i see is the versioning of releases, for my part I have not seen a project that does this.

I can think on hacks on how to limit the version for only a module using retract on the others but it will be a heavy burden to maintain.

Have you seen this done somewhere @rsevilla87? it would be nice to have an idea on how it has been done before.