consider switching to `google-re2` and `Filter`

[junyer]

google-re2 is a drop-in replacement for the re module that also offers Set and Filter. ua-parser/uap-cpp#38 describes why you might want to consider using the latter.

[mattrobenolt]

Do we know if all of the patterns in uap-core would be re2 compatible?

I'm just not very aware of what features we need to support, obviously if we need backtracking or something, we can't. I think there are cases where some patterns are syntactically different than PCRE too.

So I guess that'd be first step. If it would be compatible, I think being able to support google-re2 optionally would be good, rather than a hard requirement on it.

[junyer]

Do we know if all of the patterns in uap-core would be re2 compatible?

I believe so because ua-parser/uap-cpp#26 describes the due diligence done (back in 2019) before switching to RE2. I make no claim regarding the correctness or otherwise of that switch; it's just a data point.

So I guess that'd be first step. If it would be compatible, I think being able to support google-re2 optionally would be good, rather than a hard requirement on it.

How would you prefer that optionality to work? I'm aware of extras_require, for example, which I think entails running pip install ua-parser[RE2] and thus makes that dependency on RE2 explicit, not opportunistic. However, given that other re2 modules exist, hooking up a maybe-import in user_agent_parser.py probably wouldn't be especially elegant. Thoughts? :)

[mattrobenolt]

Yeah, thinking it can be something in extras_require and/or just use something simple like:

try:
    import re2 as re
except ImportError:
    import re

or whatever the compatibility shim would need to be, I assume it wouldnt' need to be too complex, but I know nothing about google-re2 explicitly, just RE2 in general. :)

Unless you're suggesting that there are multiple common modules that exist as import re2, in which case, this all seems complicated even if we explicitly declare it as a dependency, since someone may have multiple variants installed. That seems like a bigger issue.

[junyer]

Before google-re2, there was pyre2, re2, sw-re2, … and all of them expect to be installed (and imported) as re2. We should really "probe" for Filter as well, I suppose.

[mattrobenolt]

Given that's the state of the ecosystem, it'd probably be best we don't require one in our installation since it's a higher chance of conflicting with another project maybe explicitly or implicitly depending on one of the competing re2 imports, which can likely break programs for people.

I'd rather, as you suggest, expand the detection and see if we have the google-re2 lib installed explicitly by some deeper feature detection.

Looking briefly at the code, it seems the C module can be imported at _re2 so maybe some detection off of that?

[junyer]

The _re2 extension has more or less the same problem with regard to naming collisions, I suspect, so "probing" for Filter within the re2 module seems like about the best that we can do, but that would arguably also be in the spirit of duck typing.

I can hopefully find some time soon to put together a PR for this. The lawyer🐈s have advised me to try to tidy up a couple of things for compliance reasons; I will file a separate issue about that.

[junyer]

Okay, I took a look and had a think and... it's complicated. FilteredRE2 keeps an array of the RE2 objects; I want to make a couple of tweaks such that Filter exposes them so that callers don't have to duplicate them. I will need to think a lot more about achieving optionality in user_agent_parser.py without introducing inefficiencies or intrusive, ugly hacks.