It’s the best one for Python in my opinion. Pretty easy to work with.
There also a tmux and vim clone that uses prompt_toolkit iirc.
My usecase involves embedding a text editor widget inside my TUI app with vim keybindings enabled, and I don't think that Textual yet has a way to do that. But on the other hand it looks like Textual has a way bigger library of pre-built widgets for full-screen applications.
prompt_toolkit started as a tool for REPLs and eventually grew a basic full-screen application mode, so there's excellent support for text editing and the widget stuff is a lot less mature. It looks like Textual started as a tool for full-screen apps and has a great widget library but the text-editing widget is much less mature.
My application started as a CLI and I gradually added TUI elements around the command bar, and prompt_toolkit is definitely the best for something like that. I think that if your plan is something more similar to a webapp and you want to rely on a component library then Textual would probably be better.
This is the classic trade-off between convention and configuration.
You can prefer a tech stack that values convention over configuration, while others prefer the opposite.
This is totally fine.
Python applications vary widly. Having a single standard option for packaging that is good enough for all isn't the core language goal.
with no choice comes responsibility too, it's just that neither are yours, and likely aren't what you'd want.
edit: at this time, incidentally, i'm choosing to not use the VC-backed out-of-ecosystem toolchain (ruff, uv); pipx and setuptools do just fine.
C# doesn't have this problem, for example -- though it has others. My (very brief) contact with rust crates as a user suggests that rust does; elisp/emacs absolutely does, and in spades; js might but i've never written a line so i don't know.
end of the day, python solves my business needs, so I've learned to walk the tangle. So much so that it makes sense, usually...
Perhaps not with pipx itself, but as a symptom of what's wrong with Python (and most software nowadays) there are lots of problems with it: Everything is such huge stacks of stuff built on other stuff built on other stuff built on other stuff... All huge tottering heaps of infrastructure where shit can (and does) go wrong in every layer. It's package managers running in containers calling dynamically-linked libraries running on virtual machines calling package managers running in containers calling dynamically-linked libraries running on virtual machines...
With, say, Turbo Pascal you compiled your code into a .COM file, copied it to a floppy, and people ran it. Just your program. On their OS. No heaps of layers of infrastructure and toolchains to get knotted into a tangle of failing interdependencies. How the fuck can it be so impossible to build stuff like that nowadays?!?
Not that I'm blaming pipx (whatevertheheck that is; judging from the name seems to be a relative of pip's, which I've heard of) in particular, or even Python itself, more than anything else. Almost everything nowadays seems to be that way. I just wrote all this in the hope that it might explain why a lot of us (like for instance your interlocutor saghm in a sibling thread) are rather reluctant to pick up all the New[1] Shiny stuff. It all seems to so inevitably bring with it rat's nests -- colonies of rat's nests! -- of interdependent cruft tangled up into tight balls of mud and misery. You lose the will to even start trying anything out.
___
[1]: And yeah, OK, calling Python "New" might be problematic... If we'd gotten around to picking it up some fifteen years ago it might still have been. And maybe not accrued as many layers of cruft.
Go or Java PicoCLI with graalvm gets you pretty close to this ideal. (Now Desktop GUI is a fallen idea and we are talking about CLIs).
Anyway you're blaming the wrong thing. What pipx and venv do in python is fairly simple stuff. It's pretty reliable on standard setups. The problems if any come from C libraries.
The NodeJS Electron stack / docker / kubernetes you can feel free to blame.
Oh yippee, only one unnecessary VM layer. :-(
> Now Desktop GUI is a fallen idea and we are talking about CLIs
??? WTF are you talking about? In the real -- i.e. boring old enterprisey -- world, people work in desktop GUIs. (Except of course where those have been replaced by shitty Web-browser UIs.)
I should check out pgcli too when I use Postgres in the future.