We should revert dependency on the more performant github.com/grafana/regexp instead of the standard regexp package. It was pointed out by @dims that we end up forcing this dependency on projects using this library, and @bboreham reinforced that the performance improvements are not important enough to force a dependency on this library.
From Slack:
@dims:
[dependency] Need for grafana/regexp? 🧵
[...]
149efd6 was recently added that introduced the new package. given that repo was for something missing in go1.22, do we need to switch over?
[...]
Can we confirm why we need it?
@aknuds1:
I switched prometheus/common to grafana/regexp only to harmonize with prometheus/prometheus. It's encoded in prometheus/prometheus/.golangci.yml to use grafana/regexp, so I ported that rule over to prometheus/common. I just know that grafana/regexp has performance optimizations.
Do you mean that the optimizations in grafana/regexp are now upstream?
@dims:
yep, Bryan can you please confirm?
@bboreham:
not all of them
But we should only put that dependency in programs like Prometheus, not in libraries.
Other programs using prometheus/common can make their own choices.
[I made a slight mental error above.
For total correctness: I was thinking projects downstream can override in go.mod, but this is not true for stdlib packages.]
However I still think it's best to leave this dependency out of prometheus/common, unless it is shown to make a massive performance difference.
We should revert dependency on the more performant
github.com/grafana/regexpinstead of the standardregexppackage. It was pointed out by @dims that we end up forcing this dependency on projects using this library, and @bboreham reinforced that the performance improvements are not important enough to force a dependency on this library.From Slack:
@dims:
@aknuds1:
@dims:
@bboreham: