Python custom_builtins are great, but the callback's BuiltinContext only exposes name, argv, stdin, env, and cwd, and there's no way to read or write the virtual filesystem from inside the callback.
The existing entry points (Bash.read_file(), Bash.fs()) are intentionally rejected from within a builtin (the __init__ docstring warns against reentrant calls, and in practice they panic with "Cannot start a runtime from within a runtime"). So a Python builtin can't see the files the surrounding script is working with.
Being able to do ctx.read_text(path) / ctx.write_text(path, ...) from the callback would make custom builtins much closer to first-class with native commands. The Rust core BuiltinContext already carries fs: Arc<dyn FileSystem>, but the Python binding's BuiltinContext doesn't surface it.
Is there a deeper/intentional reason the VFS isn't exposed to Python builtins? I see from these comments that adding these would be a reasonable follow-up.
I'd be happy to open a PR if this sounds reasonable!
Python
custom_builtinsare great, but the callback'sBuiltinContextonly exposesname,argv,stdin,env, andcwd, and there's no way to read or write the virtual filesystem from inside the callback.The existing entry points (
Bash.read_file(),Bash.fs()) are intentionally rejected from within a builtin (the__init__docstring warns against reentrant calls, and in practice they panic with "Cannot start a runtime from within a runtime"). So a Python builtin can't see the files the surrounding script is working with.Being able to do
ctx.read_text(path)/ctx.write_text(path, ...)from the callback would make custom builtins much closer to first-class with native commands. The Rust coreBuiltinContextalready carriesfs: Arc<dyn FileSystem>, but the Python binding'sBuiltinContextdoesn't surface it.Is there a deeper/intentional reason the VFS isn't exposed to Python builtins? I see from these comments that adding these would be a reasonable follow-up.
I'd be happy to open a PR if this sounds reasonable!