File / lines: src/gmaps_scraper/selector_recipes.py (whole file); src/gmaps_scraper/place_scraper.py; src/gmaps_scraper/__init__.py
Problem: selector_recipes.py defines selector recipes and is exported from the public API (default_place_selector_recipe, load_place_selector_recipe, write_default_place_selector_recipe). However, it is only used to write a debug artifact in debug_dump.py. The real extraction logic hardcodes the same selectors in _PLACE_JS_EXTRACTOR and helper JS strings. Users can load a custom recipe, but it has no effect on extraction.
Why it matters: This creates an orphan abstraction. Users have false expectations, and selector changes must be maintained in two places.
Suggested fix (choose one):
- Option A: Generate the JS evaluator from the recipe so custom recipes actually drive extraction.
- Option B: Remove the module from the public API and stop writing
selector-recipe.json in debug dumps.
Add tests for whichever option is chosen.
Difficulty: medium
Impact: Medium — improves maintainability and API honesty.
File / lines:
src/gmaps_scraper/selector_recipes.py(whole file);src/gmaps_scraper/place_scraper.py;src/gmaps_scraper/__init__.pyProblem:
selector_recipes.pydefines selector recipes and is exported from the public API (default_place_selector_recipe,load_place_selector_recipe,write_default_place_selector_recipe). However, it is only used to write a debug artifact indebug_dump.py. The real extraction logic hardcodes the same selectors in_PLACE_JS_EXTRACTORand helper JS strings. Users can load a custom recipe, but it has no effect on extraction.Why it matters: This creates an orphan abstraction. Users have false expectations, and selector changes must be maintained in two places.
Suggested fix (choose one):
selector-recipe.jsonin debug dumps.Add tests for whichever option is chosen.
Difficulty: medium
Impact: Medium — improves maintainability and API honesty.