Context
When openant is invoked while another openant invocation is already running, two concurrent pip install -e <core> calls can race on the same ~/.openant/venv/. pip is not safe under concurrent installs to the same environment — typical failure modes include corrupted RECORD files, partial wheel extraction, and broken .dist-info metadata.
Two related code paths today have inconsistent treatment of this concurrency problem:
The gap
For users with even simple parallel workflows (e.g. openant scan A & openant scan B, or two terminals doing openant parse <repo> simultaneously), the venv install path can race. JS bootstrap is safe; venv install is not.
Proposed approach
Add a Go-side file lock around the pip install -e call in CheckOpenantInstalled and CheckDepsStale. Two candidate implementations:
golang.org/x/sys/unix.Flock + golang.org/x/sys/windows.LockFileEx — direct OS calls, portable behind a build-tag wrapper.
github.com/gofrs/flock — third-party, cross-platform, ~200 LOC of dependency.
Option 1 aligns better with the "no extra dependencies" preference but requires platform-specific Go files. Option 2 is one import.
Lock target: ~/.openant/venv/.deps-install.lock. Same acquisition pattern as parsers/javascript/_file_lock (block-until-acquired, re-check sentinel inside lock).
References
Context
When
openantis invoked while anotheropenantinvocation is already running, two concurrentpip install -e <core>calls can race on the same~/.openant/venv/. pip is not safe under concurrent installs to the same environment — typical failure modes include corruptedRECORDfiles, partial wheel extraction, and broken.dist-infometadata.Two related code paths today have inconsistent treatment of this concurrency problem:
parsers/javascript/.openant-npm-install.lockusingmsvcrt.lockingon Windows andfcntl.flockelsewhere. Concurrent JS scans serialize cleanly.apps/openant-cli/internal/python/runtime.go::CheckDepsStale. No lock. The stated rationale was that Go's stdlib doesn't have a portableflockequivalent on Windows.The gap
For users with even simple parallel workflows (e.g.
openant scan A & openant scan B, or two terminals doingopenant parse <repo>simultaneously), the venv install path can race. JS bootstrap is safe; venv install is not.Proposed approach
Add a Go-side file lock around the
pip install -ecall inCheckOpenantInstalledandCheckDepsStale. Two candidate implementations:golang.org/x/sys/unix.Flock+golang.org/x/sys/windows.LockFileEx— direct OS calls, portable behind a build-tag wrapper.github.com/gofrs/flock— third-party, cross-platform, ~200 LOC of dependency.Option 1 aligns better with the "no extra dependencies" preference but requires platform-specific Go files. Option 2 is one import.
Lock target:
~/.openant/venv/.deps-install.lock. Same acquisition pattern asparsers/javascript/_file_lock(block-until-acquired, re-check sentinel inside lock).References
apps/openant-cli/internal/python/runtime.go—CheckDepsStaleandCheckOpenantInstalledare the call sites needing the locklibs/openant-core/parsers/javascript/test_pipeline.py::_file_lock— reference impl