Idea: move mimir go client into own package

[Syndlex]

What is the problem you are trying to solve?

help opensource community use mimir's api to build IaC tools

Which solution do you envision (roughly)?

Extract everything that is in: https://github.com/grafana/mimir/tree/main/pkg/mimirtool/client into its on go package.

Have you considered any alternatives?

writing everything by myself

Any additional context to share?

I think it's interesting that you have this code in multiple repositories yourself.
You can find it in Grizzly, Mimir Tools, and Alloy.

How long do you think this would take to be developed?

Small (<= 1 month dev)

What are the documentation dependencies?

No response

Proposer?

No response

[pracucci]

I'm not against the proposal, but what's the problem directly importing pkg/mimirtool/client? Why does moving it to a different package will solve the issue?

[56quarters]

I am not a fan of moving the client outside this repository and introducing another package with APIs and the obligations that come with that. Something like this was proposed before here #6677. There shouldn't be anything preventing the client from being imported as-is like Marco mentioned besides the number of dependencies that Mimir pulls in.

[Syndlex]

I think moving it out off this repo would be a bad idea too.
Moving it into its own path/package would have some benefits.
Something like PKG/client or something.

These are the benefits I see:

• Clearer communication that there is a implementation for a client.
  • For me this is the main benefit. Enable the community to build stuff for the mimir system without implementing boilerplate API code.
• When I loaded the mimirtools package it was very bloated (maybe a mistake on my side).
• There is also the dry argument but I always think this is not the best argument.
  • Currently it feels like grizzly alloy don't know that there could use this client.