Proposal: Rework metric instantiation to get-or-set from the registry

[arrdem]

At present (v0.19.0 and previously) the prometheus_client.registry.Registry class is secondary in terms of API control flow to the prometheus_client.metrics.MetricWrapperBase and subclasses in that a caller says prometheus_client.Counter() and doing so implicitly first instantiates a new metric and then registers the names it defines into the global registry.

This makes the default behavior of the library code-reloading unsafe. Today if you reload code which invokes Counter(), you get a new counter instance which encounters a name conflict when it tries to register itself.

It would be better if the primary interface first performed a get-or-set against the specified registry so that reloading would re-fetch the original counter functionally as a singleton.

The real solution is that we should be explicitly managing and lifecycling registries, but the library default behavior of using a shared global registry creates this pitfall.

[csmarchbanks]

My concern with a get-or-set feature is what if two files actually tried to create identical metrics? Then you could get unexpected behavior if the second usage started changing the metric defined in the first file. I would prefer to error in that case, but maybe I am missing something?

Another option could be to make it easier to clear an entire registry (including the default registry). Would that also help your reloading use case?