This presentation proposes the introduction of a dedicated scripting language for the Jujutsu (jj) version control system to provide a safe, powerful, and maintainable way for users to extend its functionality. The speaker argues that a scripting language would solve existing issues, such as the lack of an official extension mechanism, and would supersede current ad-hoc solutions like jj-util and UI-parsing tools. After evaluating several options based on developer-centric design principles—including being typed, having a native Rust implementation, and supporting linting—the talk advocates for using Starlark, a typed Python dialect. The vision presented is for these scripts to integrate seamlessly as natural commands, enabling complex custom workflows, pre-commit tooling, and even server-side CI logic, while remaining an optional and cross-vendor feature.
A Proposal for a Jujutsu Scripting Language
0:02:23 The Need for Scripting: The talk identifies key problems that a scripting language would solve:
It provides a formal way for users to extend Jujutsu, as jj-prefixed binaries are currently not supported.
It could replace jj-util, which is seen as a non-cross-platform "hack."
It would give tools like jiujitsu-fuzz-finder a stable API instead of forcing them to parse UI output.
It allows users to safely create custom commands with their own transaction handling.
0:04:35 Core Design Principles: The language choice is guided by developer-centric axioms for long-term maintainability:
Typed: Essential for managing large, complex scripts.
Rust-Native: The implementation must be available in Rust, Jujutsu's host language.
Linting & Deprecation: The system must allow developers to lint scripts and deprecate symbols to evolve the API without breaking users indefinitely.
0:08:44 The Chosen Language is Starlark: After considering and rejecting logic programming, dynamically-typed Rust scripting languages (Rhai, Rune), and FFI-dependent languages (Lua), the speaker proposes Starlark.
Key Takeaway: Starlark is a Python dialect that is safe, typed, has a mature Rust implementation, and provides a native set type, which is perfect for working with Jujutsu's revision sets.
0:11:38 Vision for Seamless Integration: The goal is for scripts to behave like native Jujutsu commands.
A script named upload could be run as jj upload without special flags.
The system would search for scripts in user-global, repository, and current directory configuration scopes.
Arguments would be passed naturally, with the script defining its own CLI flags (e.g., booleans, lists of revisions).
0:12:42 Future Possibilities and Advanced Use Cases: The scripting engine could serve as a foundation for powerful new features:
Building sophisticated pre-commit tooling directly within Jujutsu.
Handling complex repository filtering and mirroring workflows, potentially replacing tools like copybara.
Enabling server-side CI systems built on Jujutsu's logic.
0:15:01 Path to Implementation: The speaker outlines a collaborative and deliberate path forward:
Reinstating the formal design process to gather feedback.
Developing a working prototype for the community to test and provide feedback on.
Acknowledging that this is a long-term project that will require community involvement.
0:17:25 Scripting Language Limits: In the Q&A, it's clarified that the scripting language could theoretically be powerful enough to replace the entire built-in CLI, but this would be a massive investment requiring features like a portable shell and HTTP access abstractions.
Error: value error Invalid operation: The response.text quick accessor requires the response to contain a valid Part, but none were returned. The candidate's finish_reason is 1.