8000 Refactoring and metric wrapper unification by akx · Pull Request #313 · prometheus/client_python · GitHub
[go: up one dir, main page]

Skip to content

Refactoring and metric wrapper unification #313

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

Closed
wants to merge 10 commits into from

Conversation

akx
Copy link
Contributor
@akx akx commented Sep 29, 2018

This PR does a couple things. (If you want, I can split these into separate PRs.)

🔧 Firstly, it refactors the 1200+-line core.py into separate modules for each functionality. This does not affect imports for client code; all the same prometheus_client-provided non-underscored names are re-exported from that file. Some previously underscored names were brought into the light.

✨ Secondly (and this is what prompted me to really do this work), it fixes #210 by removing the factory function magic decorator MetricWrapper; as it was before, say, an invocation Gauge(...) could either return a Gauge object, as you'd expect, or a _LabelWrapper if you'd passed in a list of label names. This tripped up code completion (and tbqh, me :) ) and static analysis.
Instead, the six metric wrappers (Counter, Enum, Gauge, Histogram, Info, Summary) are now plain old classes (though with a slightly arcane diamond-shaped inheritance hierarchy that lets them be used both with and without .labels()).

👓 Thirdly, there was a mostly mechanical autopep8 pass to placate tox flake8 errors. (That check isn't run by CI, it seems?)

No test code was changed for this (aside from the removal of the __wrapped__ attribute as there is nothing to wrap anymore), so I would say this is backwards API compatible (with the exception of client code that might have done checks like isinstance(x, _LabelWrapper)).

I'm glad to answer any questions and/or modify things as needed! :)

akx added 10 commits September 29, 2018 12:30
Signed-off-by: Aarni Koskela <akx@iki.fi>
Signed-off-by: Aarni Koskela <akx@iki.fi>
…n core)

Signed-off-by: Aarni Koskela <akx@iki.fi>
Signed-off-by: Aarni Koskela <akx@iki.fi>
Signed-off-by: Aarni Koskela <akx@iki.fi>
Signed-off-by: Aarni Koskela <akx@iki.fi>
…s to allow for that)

Signed-off-by: Aarni Koskela <akx@iki.fi>
Also gets rid of the LabelWrapper class; all top-level metric classes can now act in both labeled and unlabeled modes

Fixes prometheus#210

Signed-off-by: Aarni Koskela <akx@iki.fi>
Signed-off-by: Aarni Koskela <akx@iki.fi>
@brian-brazil
Copy link
Contributor

I'm in the middle of adding various openmetrics-related stuff, so I'll look at this properly once that's all released. One question from a quick peek is why you need two classes to replace label wrapper.

@akx
Copy link
Contributor Author
akx commented Oct 2, 2018

With this class structure, one can do

g = Gauge(..., ['label1', 'label2'])
g.labels('v1', 'v2').set(123)

but

g = Gauge(..., ['label1', 'label2'])
g.labels('v1', 'v2').labels('v3', 'v4').set(123)

is impossible, since .labels() returns a _Gauge, which is a "leaf" metric object that doesn't have .labels().

If we want to allow .labels().labels() (with whatever semantics, either a runtime error or augmentation/replacement of the labels), that'll simplify the class hierarchy.

@akx
Copy link
Contributor Author
akx commented Oct 9, 2018

Hmm, I'm seeing deadlocks in multiproc mode in the GC collector (which is actually understandable, since GC callbacks could get triggered at any point) with this PR. @brian-brazil, do you think changing Lock() to RLock() would be safe? I'm not sure what the lock does in general in multiproc.

Haven't yet tested whether master has the same problem.

@brian-brazil
Copy link
Contributor

I suspect it does have the same problem. @tcolgate

@akx
Copy link
Contributor Author
akx commented Oct 9, 2018

Hmm, no, 0.4.0 does not have the same problem. I suspect it has to do with how .labels() metrics are initialized. Either way, this fork needs to be rebased anyway, so I'll get back to it when I can and just use 0.4.0 fttb.

Nope, just reproed it with 0.4.0. Opening a ticket.

@akx
Copy link
Contributor Author
akx commented Nov 13, 2018

Closing as superseded by #344.

@akx akx closed this Nov 13, 2018
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

Successfully merging this pull request may close these issues.

@_MetricWrapper breaks pylint argument checks
2 participants
0