Thanks! This is one of those things we only have a chance to do once so it's important to get it right. I've wanted to do it for a while (#783) although never got around to it. But if you'd like to drive the process for this it probably involves opening up a discussion on the mailing list and also joining the monthly community meeting to talk it over with people. @hwayne has some experience with tlacli which might inform the design here as well. Basically a lot of design-level work!

Thanks, that makes sense. I agree that something official and standardized, along the lines of tlacli, would deserve proper design discussion and broader planning. I will definitely take the steps you proposed.

Sorry that I did not follow the path described in Contributing.md. I thought that what I had in mind for this PR was relatively small in scope: not to define a new CLI, but just to make the existing tooling a bit easier to invoke. Basically, a thin wrapper around what already exists, with tla2tools remaining the source of truth.

That said, if supporting a Homebrew formula is also part of the goal (like I had in mind), then I understand the concern that changing the CLI later could become awkward.

No worries, I think this is a good initiative. We've just been dragged down by backwards compatibility stuff for current command-line tooling creating a not-so-great experience (for example: requiring the -error-codes flag to SANY to actually return a nonzero exit code on failure) that I think it is worth it to spend a lot of time thinking about what we want these commands to look like. It would also be fine to prototype release them with the message that these commands can change at any time, since sharp edges are only found with use. But yeah, looping in other people is a good idea.

Since TLCI is referenced in this PR, I’d like to highlight a broader design consideration: we should aim to move as much functionality as possible into tla2tools.jar, keeping any wrapper script minimal and lightweight.

At the same time, TLC.java is difficult to modify due to legacy constraints. However, there’s no inherent limitation preventing us from introducing a new entry point—such as TLC2.java (or a better-named alternative)—that the wrapper script can delegate to. This new class could define a cleaner, more flexible command-line interface without being bound by the constraints of the existing implementation.

@lemmy so you're thinking the wrapper script should do very little CLI arg parsing/translation and such, and instead just be a thin wrapper around the new entrypoint so people don't have to run java -cp tla2tools.jar new.entrypoint.name? I think that seems like a good approach, as otherwise the CLI wrapper script seems likely to grow in size and then suddenly we are maintaining a bunch of bash code (and possibly fish code or whatever other shells we want to support).

@suckrowPierre there is a virtual TLA+ community meeting next week on Tuesday if you would like to join and discuss this work! https://zoom-lfx.platform.linuxfoundation.org/meetings/tla?view=month

@ahelwer ah sorry, I just saw your message now. I will try to join the next one.