Summary
On Windows, indexing a Markdown file with the libr CLI fails because the Markdown parser calls POSIX-only signal.SIGALRM. Windows Python does not expose SIGALRM, so the file is not indexed.
A second automation concern: in my repro, libr add printed Indexed: 0 and Errors: 1, but the process still exited with status code 0.
Environment
- OS: Windows / PowerShell
- Python: 3.13 from the Microsoft Store path
- Install/run method:
uvx --from agent-library libr ...
- Package:
agent-library current PyPI release as of 2026-05-11, observed as 0.13.0
Minimal Reproduction
mkdir agent-library-sigalrm-repro
cd agent-library-sigalrm-repro
@"
# Synthetic Markdown Fixture
This is a small Markdown file used only to reproduce Windows indexing.
"@ | Set-Content -Encoding UTF8 .\fixture.md
$env:DOCUMENTS_PATH = (Resolve-Path .).Path
$env:DATABASE_PATH = (Join-Path (Resolve-Path .).Path "library.db")
$env:EMBEDDING_PROVIDER = "local"
$env:EMBEDDING_MODEL = "all-MiniLM-L6-v2"
$env:LIBRARIAN_ENABLE_OPTIONAL_TOOLS = "false"
uvx --from agent-library libr add . --verbose
Expected Behavior
The Markdown file should be read and indexed, or the CLI should fail with a non-zero exit code if indexing cannot complete.
Actual Behavior
The CLI reports the source as added, but the file is not indexed:
Source added and indexed!
Files found: 1
Indexed: 0
Errors: 1
The traceback is:
AttributeError: module 'signal' has no attribute 'SIGALRM'. Did you mean: 'SIGABRT'?
File "...\site-packages\librarian\processing\parsers\base.py", line 64, in safe_read_text
old_handler = signal.getsignal(signal.SIGALRM)
In the observed run, the shell command exited with status code 0 even though indexing had Errors: 1.
Likely Cause
safe_read_text() appears to rely on signal.SIGALRM / signal.alarm, which is a POSIX-only timeout mechanism. Windows-compatible alternatives would avoid this failure path, for example using a different timeout implementation or skipping the alarm path on platforms that do not support it.
Workaround Used Locally
For a local project smoke test, I temporarily added a process-local sitecustomize.py shim that defines signal.SIGALRM and a no-op signal.alarm before invoking libr. That allowed the Markdown parser to proceed on Windows. This is only a workaround; the upstream parser should not require a POSIX-only signal on Windows.
Summary
On Windows, indexing a Markdown file with the
librCLI fails because the Markdown parser calls POSIX-onlysignal.SIGALRM. Windows Python does not exposeSIGALRM, so the file is not indexed.A second automation concern: in my repro,
libr addprintedIndexed: 0andErrors: 1, but the process still exited with status code0.Environment
uvx --from agent-library libr ...agent-librarycurrent PyPI release as of 2026-05-11, observed as0.13.0Minimal Reproduction
Expected Behavior
The Markdown file should be read and indexed, or the CLI should fail with a non-zero exit code if indexing cannot complete.
Actual Behavior
The CLI reports the source as added, but the file is not indexed:
The traceback is:
In the observed run, the shell command exited with status code
0even though indexing hadErrors: 1.Likely Cause
safe_read_text()appears to rely onsignal.SIGALRM/signal.alarm, which is a POSIX-only timeout mechanism. Windows-compatible alternatives would avoid this failure path, for example using a different timeout implementation or skipping the alarm path on platforms that do not support it.Workaround Used Locally
For a local project smoke test, I temporarily added a process-local
sitecustomize.pyshim that definessignal.SIGALRMand a no-opsignal.alarmbefore invokinglibr. That allowed the Markdown parser to proceed on Windows. This is only a workaround; the upstream parser should not require a POSIX-only signal on Windows.