Package structure disallows wrapping of Exporter

[schmikei]

I'm submitting a ...

• feature request

What is the current behavior?

Currently the majority of the code is inside of a main package which disallows it to be imported thus requiring a fork in order to import this software into other Go applications.

You cannot import the main package. Any shared code should go in a separate package, which can be imported by main (and other packages).

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

N/A

What is the expected behavior?

I believe this exporter should follow the conventions of introducing a collector package and keep the main.go to just worry about being able to starting the exporter.

Examples:

• https://github.com/Lusitaniae/apache_exporter/
• https://github.com/grafana/snowflake-prometheus-exporter
• https://github.com/infinityworks/github-exporter
• https://github.com/burningalchemist/sql_exporter
• https://github.com/oliver006/redis_exporter

What is the motivation / use case for changing the behavior?

I would like to use the actual non-forked package in https://github.com/grafana/agent

More Context

I'm happy to open PRs and help do the refactor in the way the maintainer feels appropriate. I currently have an experimental fork at https://github.com/observiq/oracledb_exporter/ as a workaround but would love to contribute upstream properly!

Let me know if this is something the maintainers would like to see!

[Yannig]

Hi,

PR are welcome in order to split and clean up the code :)

So no problem if you want to do it.