Required dependency on ua-parser-rs and stub package?

[masklinn]

Awareness problem

pypi doesn't expose reverse dependencies so it's hard to know what users ua-parser has exactly, but going by the difference between ua-parser-builtins and ua-parser-rs it does look like most people don't know about the native engine and thus don't benefit from the higher performance¹². This is confirmed by finding no dependency on ua-parser[regex] in the projects which have updated to 1.0 in github's dependency graph³. Furthermore PRs like selwin/python-user-agents#131 hint that people are confused by this as the reason for the bump to 1.0 is stated as

allows the use of new builtin resolvers that give a significant performance boost

but the updated requirements.txt does not set [regex], and the package does not otherwise depend on re2. This means installing user-agents will install the "bare" ua-parser with no native acceleration at all, users of user-agents have to know about the native accelerators and install one separately to actually benefit.

Proposal

Moving ua-parser-rs to a required dependency and adding a stub pure wheel, so people running on compatible machines & interpreters get the recommended accelerator out of the box.

Drawbacks

• people who already have a dependency on re2 would get regex on top of that for a minimal gain, and extra storage (and to a lower extent higher memory use)
• people who specifically do not want accelerators for some reason (most likely memory constraints?)

Breaking change?

Yes and no? From an "existing runtime" perspective not, but (assuming no bug in the backends) there might be systemic behavioural change from the "drawbacks" on any new install, which is not amazing and might require a version bump to 1.1? Also change from the regex backend not using caches by default, if people use the caches themselves.

Alternatives

Default Extras for Python Software Packages

Wait for and use that instead, this does not fix the drawbacks entirely as they'd still be there by default, but users would at least be able to opt out of the feature which is better.

Also may not require a stub wheel, I'm not finding anything on selection issues in the current state of the PEP.

Environment markers

Would avoid the need for a stub universal wheel, but would require matching the environment markers of ua-parser with the supported platforms of ua-parser-rs every time (at which point it would probably make sense to move ua-parser-rs from ua-parser/uap-rust to ua-parser/uap-python, this would also be even more of a reason to switch to implement #272 and use proper workspaces)

Footnotes

1. there's been a massive bump in ua-parser-rs use in December: stats jump from ~10k to ~100k between Dec. 07 and Dec. 0 and I've no idea why, there's no such pattern in ua-parser or ua-parser-builtins, -rs also has a much less severe weekend dip, just a few thousands instead of the halving of the other two ↩ ↩²

2. the 0.x problem is implicitly ignored from comparing -builtins and -rs, both of which are post-1.0 dependencies. Lingering 0.x dependencies are probably visible in the stats difference between ua-parser and ua-parser-builtins, which is about 20% ↩

3. although I didn't check every single project, and using github's global search does find various matches, if not any recent enough to explain ¹ ↩