PlaceCoordinateGramplet: move geocoding from GeocodeGlib 1.0 (libsoup 2) to 2.0 (libsoup 3)

[eduralph]

Summary

PlaceCoordinateGramplet does all its geocoding through GeocodeGlib 1.0,
which links libsoup 2. Modern distros ship only GeocodeGlib 2.0 (libsoup
3) and no longer provide the 1.0 typelib, so on those systems the gramplet's
geocoding is silently broken — the gramplet still loads, but every
place-name→coordinates and coordinates→place-name lookup fails. This issue
records why, and exactly what's needed to move it to GeocodeGlib 2.0 / libsoup 3.

Background: the libsoup 2 ↔ 3 split

GeocodeGlib (geocoding) and osm-gps-map (the map widget the gramplet's
GeoView uses) both link libsoup directly for HTTP. libsoup 2 and libsoup 3
cannot coexist in one process. The mapping is:

• GeocodeGlib 1.0 → libsoup 2
• GeocodeGlib 2.0 → libsoup 3
• osm-gps-map historically → libsoup 2, but has since been rebuilt against
  libsoup 3 on current distros.

History (current addons-source git log)

• e77a89829 (2020-08-21) — set use_geopy = False, making GeocodeGlib the
  sole active geocoding backend.
• c1ab63874 (2023-10-04, Nick Hall) — "Update Place Coordinate addons to
  require GeocodeGlib 1.0 or 2.0": a for ver in ('2.0','1.0') require loop +
  requires_gi=[('GeocodeGlib','1.0,2.0')].
• 603b70a87 (2023-10-05, Nick Hall) — reverted it the next day, reason:
  "GeocodeGlib 2.0 requires libsoup 3.0 which is not compatible with
  osm-gps-map which requires libsoup 2.0."

So the 1.0 pin is a deliberate maintainer decision, correct at the time.

What changed: the blocker is gone on modern systems

The 2023 conflict no longer holds where osm-gps-map has moved to libsoup 3.
Verified on Ubuntu 24.04 (ldd):

package	version	links
libosmgpsmap-1.0-1	1.2.0-4build1	libsoup-3.0
libgeocode-glib-2-0	3.26.4-3	libsoup-3.0
libsoup-3.0-0	3.6.6-1	— (no libsoup-2.4 installed at all)

Both are now on libsoup 3 — consistent, loadable together. The Gramps Windows
AIO build is the same stack (aio/build.sh installs
mingw-w64-ucrt-x86_64-geocode-glib + …-osm-gps-map; aio/setup.py bundles
libgeocode-glib-2-0.dll + libosmgpsmap-1.0-1.dll). So GeocodeGlib 2.0
alongside osm-gps-map — impossible in 2023 — is exactly what current platforms
ship.

Current behaviour on a modern system

• PlaceCoordinateGramplet.py:40 / PlaceCoordinateGeoView.py:74:
  gi.require_version('GeocodeGlib', '1.0') raises (only 2.0 exists), but it's
  inside a bare try: … except: pass, so the error is swallowed and
  GeocodeGlib is never bound — the gramplet loads.
• use_geopy = False is hard-coded (PlaceCoordinateGramplet.py:32), so the
  geopy branch is dead and GeocodeGlib is the only path that runs.
• Every geocode call then hits NameError: name 'GeocodeGlib' is not defined,
  caught and shown to the user as "Failed to search … unexpected error."

API compatibility — verified, no call-site changes needed

Introspected the installed GeocodeGlib 2.0 (3.26.4-3); every symbol the
addon uses is present and unchanged:

• Forward.new_for_string, Forward.search (sync) — OK
• Location.new, Location.get_latitude / get_longitude — OK
• Reverse.new_for_location, Reverse.resolve (sync) — OK
• Result Place is read generically via list_properties() / get_property();
  every property the addon consumes exists on 2.0's Place: location,
  building, street, area, town, county, state, country.

So the geocoding logic ports as-is. The work is purely version selection +
declaration.

What must be done

1. Version-tolerant import (both PlaceCoordinateGramplet.py and
   PlaceCoordinateGeoView.py) — replace the hard require_version('…','1.0')
   with a try-2.0-then-1.0 loop and a real availability flag (essentially
   Nick's reverted approach, now valid):

   _GEOCODE = False
   for _ver in ('2.0', '1.0'):
       try:
           gi.require_version('GeocodeGlib', _ver)
           from gi.repository import GeocodeGlib
           _GEOCODE = True
           break
       except (ImportError, ValueError):
           continue

   Order matters: prefer 2.0 so the modern (libsoup 3) stack is matched; fall
   back to 1.0 for older systems.
2. requires_gi (both register() blocks in
   PlaceCoordinateGramplet.gpr.py:36,55): ('GeocodeGlib', '1.0,2.0') —
   Gramps accepts comma-separated version alternatives.
3. Stop swallowing the import failure. Replace the bare try/except: pass
   with the _GEOCODE flag; have the geocode handlers check it and show a clear
   "geocoding unavailable" message (and log via the module _LOG) instead of
   surfacing a NameError as a generic "unexpected error".
4. No call-site edits for the GeocodeGlib API itself (verified above) — keep
   the diff minimal.
5. Dead use_geopy switch (separate cleanup, optional): use_geopy = False
   is hard-coded and the geopy branch is unreachable. Either remove it or wire
   it to a real config/fallback. Out of scope for the libsoup-3 move but worth a
   follow-up.

Why a fallback, not a hard switch (important)

Do not hard-pin 2.0. On long-support / enterprise distros (RHEL 8/9 & rebuilds,
SLES 15, Ubuntu 22.04, Debian 11) osm-gps-map is still libsoup-2-linked and only
GeocodeGlib 1.0 exists; there, loading GeocodeGlib 2.0 (libsoup 3) alongside
the libsoup-2 map would re-create the 2023 abort. The try-2.0-then-1.0 order keeps
those users working while un-breaking modern ones.

Open risk to validate: the loop assumes the system is internally consistent —
that osm-gps-map and the preferred GeocodeGlib share a libsoup major. On a
transitional distro that co-packages both libsoup majors (e.g. Debian 12), it's
conceivable to have osm-gps-map on libsoup 2 while GeocodeGlib 2.0 (libsoup 3) is
also installed; there the naive "2.0 first" pick would clash with the map. A
fully robust fix would detect osm-gps-map's libsoup major and choose GeocodeGlib
to match. Worth confirming whether that combination occurs in practice before
deciding the loop is sufficient.

Verification plan (no automated tests — GUI + network + GI)

The addon ships no test suite and these paths are GUI/network-bound, so manual:

• Modern (Ubuntu 24.04 / libsoup3 + geocode-glib-2 + osm-gps-map): forward
  search (place name → lat/lon) and reverse (coords → place name) both succeed,
  and the GeoView map loads with no libsoup 2/3 abort.
• Older (Ubuntu 22.04 / Debian 11, libsoup2 + GeocodeGlib 1.0): falls back to
  1.0 and still works.
• Windows AIO (MSYS2, geocode-glib-2 + osm-gps-map): geocoding works.

References

• PlaceCoordinateGramplet/PlaceCoordinateGramplet.py:32,40,223,259-261,290-292
• PlaceCoordinateGramplet/PlaceCoordinateGeoView.py:74,704-707
• PlaceCoordinateGramplet/PlaceCoordinateGramplet.gpr.py:36,55
• Commits e77a89829, c1ab63874, 603b70a87