Has Anyone Created an Interactive, Tab-Completed CLI with Textual?

[TheTechromancer]

There seems to be a lot of potential for something like this -- e.g. an interface with one window for issuing commands, and another for tailing logs, monitoring performance, etc.

I am the creator of BBOT and I'm working on an interactive console front-end. Textual seems like a cool option, but I can't find an example of anyone else doing this.

I'm imagining something metasploit-like; possibly using cmd2:

I've made several small attempts at putting a cmd2 program inside a textual widget, but without success. Has anyone succeeded in creating an interactive, tab-completed CLI using textual?

Related: Textualize/rich#2406

[willmcgugan]

It is very doable. Have a look at the mother.py example, it is an LLM chat interface, but functionally similar to what you at proposing.

[TheTechromancer]

Thanks, I'll check it out.

[brandon-fryslie]

People have been asking for this functionality for years, and I’ve been looking off and on for about a year. Right know I just write my TUIs without any framework but I’d like to be able to use Textual since most of my stuff is written in Python. By far the biggest blocker is the general lack of support for standard terminal use cases such as a Console w/ a repl.

I looked at the Mother example. It’s incredibly basic and lacks most of the functionality that is necessary to make a real useful terminal program. Yes you can type text into a thing and put text into a panel above it. But that’s the easy part. A console needs to be able to stream output from live processes (ideally multiple but even one would be great) and display that correctly, with scrollback. There needs to be some concept of a command history, basic line editor shortcuts need to work, there needs to be some concept of tab completion baked in. If we had something like that in Textual, the community can fill in the gaps.

You might say “well, why don’t you build it? We built all the primitives so the community can build what they need!” That’s a good point, but I think there are a few things to think about:

• To many terminal users, a console is THE foundational primitive. It’s what we interact more than anything else on the terminal. the terminal is popular not because of it’s incredible ergonomics or it’s stunning good looks, but precisely because this interface is so flexible and powerful.
• When you say “terminal” this is what people picture in their heads. You’d think it would be the first widget out the door, the cornerstone around which the structure is designed. And yet when I look at the docs at the widgets? The first item is “Button”.
• How many terminal programs require a repl or console to provide their core functionality? As in, they would be substantially different pieces of software without that. Now think about how many programs “need” buttons. Has there been a single occasion where someone was writing a terminal application and they thought “you know what this terminal application needs to really take it to the next level? The feature that’s going to truly delight the users and fulfill the needs they didn’t even know they had? BUTTONS!”

I want to use Textual. I think it’s neat. I have my repl and I’d love to add a little footer and maybe put some stuff into collapsible log panels and have some modal screens and whatnot. I think there are probably other users out there like me, who would use like to use Textual. The problem is Textual lacks support for the most common types of terminal applications. It’s like having the most delicious hamburger toppings, fresh baked buns, pickles, sauces, all the veggies and cheeses, but you get there and there’s no burger. Burger is like “oh just go down to the store and get some meat and make your burger! It’s easy. Look, there’s some ham over on a tray over there, I’d bet you can cobble something together without too much work”.

Here’s the thing, ham and hamburgers are not the same thing. And if I’m going to the store already, it’s a lot of effort to cook my burger and bring it al the way back here and try to integrate it with your stuff. I can slice an onion at home even if it’s not as pretty. If I have to cook my burger at home anyway, what exactly is the motivation for me to bike an extra 10 miles just to use your onions? The value is there, possibly, but it’s certainly not decisive.

I think you want people to use your framework. If so, at the risk of sounding obvious, it would be helpful to implement functionality that makes life easier for people writing terminal applications today. I write a lot of terminal applications and am happy to give some input if desired. First on my list would be: REPL widget. 2nd: Console widget. The community can take it from there.

Now I am not criticizing you or your work, which I think is great. What I am doing is running through a potential train of thought by someone considering adoption. Consider this insight into how an archetypal customer/user might think of the project, and NOT “hey here is me kind of demanding you do X”. I really am not. This comment is written from a single perspective that is not comprehensively representative of my own. I think you’ve done some amazing work and the last thing I’d want to do is be ungrateful or rude. I truly appreciate your contributions to software engineering. You can do whatever you want and I support that either way, and hope you have a wonderful rest of your day. Take care.

[darrenburns]

I think you misunderstand what Textual's goals are. It's for building fullscreen, interactive terminal applications. It's not targeting people who want to build CLIs. If anything, it's offering an alternative to CLIs.

A console/REPL within a TUI is a pretty niche requirement, and I haven't seen too much of an appetite for it among Textual users.

When you say “terminal” this is what people picture in their heads. You’d think it would be the first widget out the door, the cornerstone around which the structure is designed. And yet when I look at the docs at the widgets? The first item is “Button”.

You're imagining Textual to be something it's not. I can say with certainty that the number of people needing buttons is orders of magnitude greater than those wanting a REPL/console widget.

You might say “well, why don’t you build it?"

Frankly you didn't really answer why you won't build it... Textual does provide the primitives and they're easy enough to glue together and customise to your liking. Pretty much all of the requirements you listed in your post either exist already or would be relatively simple to implement after a bit of practice working with Textual (seriously, a RichLog plus either Input or TextArea gets you like 90% of the way there and keeps things easier to customise to your liking).

Consider this insight into how an archetypal customer/user might think of the project, and NOT “hey here is me kind of demanding you do X”.

No matter how much you claim this is the patty in a burger, this is actually not a typical use case at all, sorry.