Summary
The PyBioNetGen VS Code extension detects/validates bionetgen using the selected workspace interpreter, but when actually running a BNGL file it appears to spawn bionetgen by bare command name (PATH lookup). On macOS this often fails with spawn bionetgen ENOENT or runs the wrong bionetgen (e.g., from conda), because the VS Code extension host PATH can differ from the integrated terminal PATH and may not include the workspace venv.
Observed behavior
Auto-install / checks succeed:
Found python path: .../.venv/bin/python
Found bionetgen ... Location: .../.venv/lib/python3.12/site-packages
But execution fails:
bionetgen -req "0.5.0" run -i ".../model.bngl" -o "..." -l "..."
Error: spawn bionetgen ENOENT
process exited with code -2
Earlier, when a different bionetgen existed on PATH (conda), the extension ran that instead of the venv binary (tracebacks showed /Users/.../opt/anaconda3/bin/bionetgen), even though the check phase found bionetgen installed in the workspace venv.
Environment
- macOS
- VS Code + PyBioNetGen extension
- Workspace uses a repo-local venv:
${workspaceFolder}/.venv
bionetgen installed in .venv
Root cause (likely)
The extension uses the interpreter to verify package presence, but uses something equivalent to Node's child_process.spawn("bionetgen", ...) for execution, relying on PATH. The extension host PATH is not guaranteed to include .venv/bin, and can differ from the integrated terminal.
Workarounds
- Launch VS Code from a terminal where the venv is active / PATH includes
.venv/bin (requires the code shell command installed).
- Add a global shim/symlink so
bionetgen is discoverable on PATH.
- (If supported) configure the extension to use an explicit executable path or
python -m bionetgen (currently no such setting appears exposed).
Proposed fix
Prefer interpreter-based execution rather than PATH-based lookup:
- Use the selected interpreter to run the module:
python -m bionetgen ... using the resolved workspace interpreter, or
- Spawn the resolved absolute path to the venv script (the interpreter's scripts dir):
Also consider exposing a setting so users can override the executable/command explicitly.
Expected behavior
If the extension reports it is using a particular interpreter, running a model should use the corresponding bionetgen installation and must not depend on external PATH state.
Summary
The PyBioNetGen VS Code extension detects/validates
bionetgenusing the selected workspace interpreter, but when actually running a BNGL file it appears to spawnbionetgenby bare command name (PATH lookup). On macOS this often fails withspawn bionetgen ENOENTor runs the wrongbionetgen(e.g., from conda), because the VS Code extension host PATH can differ from the integrated terminal PATH and may not include the workspace venv.Observed behavior
Auto-install / checks succeed:
Found python path: .../.venv/bin/pythonFound bionetgen ... Location: .../.venv/lib/python3.12/site-packagesBut execution fails:
Earlier, when a different
bionetgenexisted on PATH (conda), the extension ran that instead of the venv binary (tracebacks showed/Users/.../opt/anaconda3/bin/bionetgen), even though the check phase foundbionetgeninstalled in the workspace venv.Environment
${workspaceFolder}/.venvbionetgeninstalled in.venvRoot cause (likely)
The extension uses the interpreter to verify package presence, but uses something equivalent to Node's
child_process.spawn("bionetgen", ...)for execution, relying on PATH. The extension host PATH is not guaranteed to include.venv/bin, and can differ from the integrated terminal.Workarounds
.venv/bin(requires thecodeshell command installed).bionetgenis discoverable on PATH.python -m bionetgen(currently no such setting appears exposed).Proposed fix
Prefer interpreter-based execution rather than PATH-based lookup:
python -m bionetgen ...using the resolved workspace interpreter, or<venv>/bin/bionetgen ...Also consider exposing a setting so users can override the executable/command explicitly.
Expected behavior
If the extension reports it is using a particular interpreter, running a model should use the corresponding
bionetgeninstallation and must not depend on external PATH state.