build: move to ontoenv 0.6.1

^0.6.0 -> ^0.6.1. The caret range already admitted 0.6.1; this raises the
floor, because the release is entirely about the failure mode
`_connect_recovering` exists to handle and the handler is only safe with it.

0.6.1 splits `.ontoenv/catalog.pending` into three states instead of two.
Before, the marker's presence at open time meant `CatalogRecoveryError`, full
stop. Now: a mutation that fails before touching the backend removes the
marker on its way out rather than leaving one (the persisted catalog still
describes the store, so there is nothing to recover); a marker whose writer
still holds `.ontoenv/store.lock` is waited on for up to 2s and then raised as
a plain retryable `ValueError` naming the external process; and only a marker
with no live writer behind it is `CatalogRecoveryError`.

That middle state is the one that matters here. `_connect_recovering` catches
`CatalogRecoveryError` and rebuilds unconditionally, which under 0.6.0 could
mean rebuilding a catalog another process was in the middle of writing --
the one destructive thing this code can do. 0.6.1 makes that unreachable, and
the retryable error propagates untouched, which is correct: the answer to it
is to retry, not to rebuild. No code change; the docstring now says so.

Verified against 0.6.1 with a persistent cache: loading Brick (whose eight
unresolvable imports were the original source of spurious markers) leaves no
marker and opens #2 and #3 succeed with all 21 ontologies intact; a
hand-written marker with no writer still raises `CatalogRecoveryError` and
`OntoEnv.recover` clears it; a marker held by a thread holding an exclusive
lock on store.lock raises `ValueError` after ~2.0s rather than
`CatalogRecoveryError`.

No API of ours changed and no new deprecation warnings: `connect`, `recover`,
`UnresolvedImportError`, and `ViewGraph` are all as they were on 0.6.0.
poetry.lock was regenerated by poetry 2.4.1 rather than the 2.1.1 that wrote
it, so it also carries that generator header and two constraint spellings it
normalizes (`jsonschema-specifications`, `PyYAML`); no other package moved.

Author: gtfierro

buildingmotif/ontology_environment.py

@@ -90,7 +90,17 @@ def _connect_recovering(
         a tolerated missing import now commits cleanly and leaves no marker, and
         ``OntoEnv.recover`` rebuilds the catalog properly.
 
-        So reaching this handler now means a genuinely interrupted write, and
+        0.6.1 narrowed the condition twice more, which is what makes catching
+        it unconditionally safe: an operation that fails before writing
+        anything no longer leaves a marker at all, and a marker still held by a
+        *live* writer is reported as a retryable ``ValueError`` after a short
+        wait rather than as ``CatalogRecoveryError``. Recovering an environment
+        another process is actively writing would be the one genuinely
+        destructive thing this method could do, and 0.6.1 is what rules it out;
+        that error is left to propagate, since the answer to it is to retry,
+        not to rebuild.
+
+        So reaching this handler means a genuinely interrupted write, and
         recovery is the supported answer to one. It is taken automatically
         because the alternative is a dead end: recovering a custom store
         requires passing that store, and ours does not exist until a

poetry.lock

@@ -41,7 +41,7 @@ werkzeug="^2.3.7"
 types-jsonschema = "^4.21.0.20240311"
 matplotlib = "^3.9.2"
 pandas = "^2.2.3"
-ontoenv = "^0.6.0"
+ontoenv = "^0.6.1"
 
 [tool.poetry.group.dev.dependencies]
 black = "^22.3.0"