Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could the LabelGroup derive re-use the user-defined struct? #3

Open
clux opened this issue Jun 24, 2024 · 0 comments
Open

Could the LabelGroup derive re-use the user-defined struct? #3

clux opened this issue Jun 24, 2024 · 0 comments

Comments

@clux
Copy link

clux commented Jun 24, 2024

This is mostly an ergonomics request more than anything.

Current

rather than creating a struct, which derives a second hidden struct:

#[derive(LabelGroup)]
#[label(set = ErrorLabelSet)]
pub struct ErrorLabels<'a> {
    #[label(dynamic_with = lasso::ThreadedRodeo, default)]
    instance: &'a str,
    #[label(dynamic_with = lasso::ThreadedRodeo, default)]
    error: &'a str,
}

and force user to refer to hidden struct ErrorLabelSet in #[metric] attrs and types ala CounterVec<ErrorLabelSet>

Proposed

is it possible to do some magic to have a hidden associated type internally so that we can just:

#[derive(LabelGroup)]
pub struct ErrorLabels<'a> {
    #[label(dynamic_with = lasso::ThreadedRodeo, default)]
    instance: &'a str,
    #[label(dynamic_with = lasso::ThreadedRodeo, default)]
    error: &'a str,
}

and refer to the user created ErrorLabels in #[metric] attributes and CounterVec<ErrorLabels>?

Hypocritical ask, because I commit the same sin myself in kube-derive, but I am painfully aware of how many people trip up on this (and it was my biggest stumbling block in measured because the errors all look so similar i start feeling dyslexic).

How

I don't know. Create the raw data type under the hood, and refer to by an associated type internally maybe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant