Summary
gramps/plugins/test/imports_test.py legacy-database load tests hard-fail when the bsddb (Berkeley DB) backend cannot be loaded, instead of skipping. On any Linux environment without the berkeleydb/bsddb3 Python library installed, the whole-suite unit run reports new failures that are environmental, not code regressions.
Surfaced while running the gramps unit suite on maintenance/gramps61 (testbed harness) — previously masked by an unrelated headless-discovery segfault; once that is fixed the suite runs to completion and these reds appear.
Failing tests (7 observed)
5× gramps.plugins.test.imports_test.TestImports, all with the same cause:
False is not true : Cannot open database .../temp/imp_<ver> can't load database backend: 'bsddb'
test_imp_3_4_5_zip, test_imp_4_1_3_zip, test_imp_4_2_8_zip, test_imp_5_0_1bsd_zip, test_imp_5_1_2bsd_zip
(Separately, test_WebCal and test_navwebpage in reports_test fail on web-report generation — likely a distinct issue; noted here only for completeness.)
Root cause
- The bsddb backend plugin is still registered as STABLE —
gramps/plugins/db/bsddb/bsddb.gpr.py (plg.status = STABLE, databaseclass = "DbBsddb").
- It imports the underlying lib —
gramps/plugins/db/bsddb/bsddb.py:33-35: from berkeleydb.db import ... with fallback from bsddb3.db import .... Neither berkeleydb nor bsddb3 is installed in modern environments, so the import (and thus make_database("bsddb")) fails.
- The suite still ships legacy bsddb-format fixtures (
imp_3.4.5.zip … imp_5.1.2bsd.zip) whose DBBACKEND marker reads bsddb.
db_load() reads the marker, calls make_database("bsddb"), the load fails → the test does assertTrue(False, ...).
- The test only skips bsddb on Windows —
imports_test.py (~L245): if dbid == "bsddb" and win(): self.skipTest("bsddb not supported on Windows"). There is no equivalent skip when the bsddb backend is simply unavailable on the platform.
Suggested fix
In db_load() (gramps/plugins/test/imports_test.py), skip when the bsddb backend cannot be loaded on any platform — e.g. generalize the existing Windows-only guard to detect an unavailable/unimportable bsddb backend (catch the load failure and self.skipTest(...)), rather than asserting failure. That keeps the legacy-format coverage where bsddb is present while not reddening environments where it has been dropped.
Notes
Not a release blocker for unrelated fixes — environmental. Filed for future work.
Summary
gramps/plugins/test/imports_test.pylegacy-database load tests hard-fail when thebsddb(Berkeley DB) backend cannot be loaded, instead of skipping. On any Linux environment without theberkeleydb/bsddb3Python library installed, the whole-suite unit run reports new failures that are environmental, not code regressions.Surfaced while running the gramps unit suite on
maintenance/gramps61(testbed harness) — previously masked by an unrelated headless-discovery segfault; once that is fixed the suite runs to completion and these reds appear.Failing tests (7 observed)
5×
gramps.plugins.test.imports_test.TestImports, all with the same cause:test_imp_3_4_5_zip,test_imp_4_1_3_zip,test_imp_4_2_8_zip,test_imp_5_0_1bsd_zip,test_imp_5_1_2bsd_zip(Separately,
test_WebCalandtest_navwebpageinreports_testfail on web-report generation — likely a distinct issue; noted here only for completeness.)Root cause
gramps/plugins/db/bsddb/bsddb.gpr.py(plg.status = STABLE,databaseclass = "DbBsddb").gramps/plugins/db/bsddb/bsddb.py:33-35:from berkeleydb.db import ...with fallbackfrom bsddb3.db import .... Neitherberkeleydbnorbsddb3is installed in modern environments, so the import (and thusmake_database("bsddb")) fails.imp_3.4.5.zip…imp_5.1.2bsd.zip) whoseDBBACKENDmarker readsbsddb.db_load()reads the marker, callsmake_database("bsddb"), the load fails → the test doesassertTrue(False, ...).imports_test.py(~L245):if dbid == "bsddb" and win(): self.skipTest("bsddb not supported on Windows"). There is no equivalent skip when the bsddb backend is simply unavailable on the platform.Suggested fix
In
db_load()(gramps/plugins/test/imports_test.py), skip when thebsddbbackend cannot be loaded on any platform — e.g. generalize the existing Windows-only guard to detect an unavailable/unimportable bsddb backend (catch the load failure andself.skipTest(...)), rather than asserting failure. That keeps the legacy-format coverage where bsddb is present while not reddening environments where it has been dropped.Notes
Not a release blocker for unrelated fixes — environmental. Filed for future work.