HuggingFaceNerRecognizer cannot be enabled from its shipped default_recognizers.yaml entry (no model_name, constructor raises)
Describe the bug
HuggingFaceNerRecognizer ships in default_recognizers.yaml (enabled: false), but the entry cannot actually be turned on. It carries no model_name, and the constructor calls load(), which raises before the registry finishes building. So the switch exists, but flipping it always crashes: the entry is not usable as shipped.
To Reproduce
# flip HuggingFaceNerRecognizer to enabled: true in default_recognizers.yaml, then:
from presidio_analyzer.recognizer_registry import RecognizerRegistryProvider
RecognizerRegistryProvider(conf_file="default_recognizers.yaml").create_recognizer_registry()
# ValueError: model_name must be set before calling load(). Pass it to __init__() or set it directly.(Requires the transformers extra to be installed; found while running an enable-everything sweep during the #2216 benchmark work.)
Expected behavior
One of: the shipped entry includes a working default model_name, or the recognizer defers load() so the registry can build and the error surfaces at analyze time with a pointer to the missing config, or the shipped entry documents inline that model_name is required to enable it. Any of these would be an improvement over an unconditional crash during registry construction.
Additional context
Found independently from two directions: my enable-everything sweep, and the constructor-coverage work in #2170, where it's currently recorded in a NOT_LOADABLE_FROM_SHIPPED_ENTRY exclusion with a guard test so the coverage gap stays visible. This issue is the tracking item for actually fixing the entry. Related: #2176, #2217.
Source: data-privacy-stack/presidio