Early feedback

[ewels]

Hi @thijsmie, @willmcgugan,

I added you both as collaborators on this repo in response to ewels/rich-click#74 so that you can have a poke if you're curious.. (although I know you already rolled your own @willmcgugan!)

There are a few bits missing and it needs a bit of spit and polish still, but any early feedback would be gratefully received 🙏🏻

This is a late-night hobby project so has been a bit stop-start in its progress.. (Likely to continue to be the case).

Phil

[thijsmie]

Hi @ewels!
I've been trying this out and I am really liking it so far! I have a couple of notes so far (I can turn them into issues if you want):

• Sometimes I don't need all the smartness that rich-codex does for me, I just need a quick image of something. Is this modular enough to also just give me a "stupid" tool that does "run this command and save it here" instead of the whole scanning routine?
• I have several things that I "screenshot" that are really examples of a scenario. They require running a background script to do some setup that are then discovered and displayed in the terminal. Do you see a way to integrate some kind of init/teardown context for a command?
• I render TUI's with rich.live.Live and Textual which rely on the alternative-screen and will run forever until ctrl-c. It would be cool to be able to "screenshot" these after N seconds and then kill them. I have no idea how feasible that is however.
• Fiddling with the terminal width "till it looks good" can be very dependend on what command is running. Would it be possible just to set it to a very high number and then let rich-codex crop to a size where it fits exactly?

[thijsmie]

Thanks for the responses! I am winding down for today, I'll split out into issues and see about contributing the pty thing. For the ctrl-c/capture tool approach I made some hidden options that limit duration and print the final UI state exactly once, so also low priority for me.

[thijsmie]

Oh and RE the other automation: we are not using GitHub actions for CI but Azure Pipelines, and anyway the init/teardown is not the same for every command that needs running, so that method will not work for me.

[ewels]

Excellent, straight in with the edge cases that I hadn't considered! 😅 You should still be able to set up some kind of CI configuration that runs rich-click multiple times for specific files / commands etc, with custom setup and teardown.

Messy and difficult to maintain, but better than nothing. And the best I can think of sorry.

[thijsmie]

Made some issues! One more thing: import pty will actually fail on Windows. I don't know if you are targeting windows, but your setup.cfg claims OS::Independent 😉.

[ewels]

ok good to know. I'm not too fussed as it's not the default, but we should maybe capture the error and fall back with a nice log message. I don't have access to any windows machines though, so could be tricky.

Which leads me to... should really write some tests 🙄

[thijsmie]

Hi @ewels!

I've noticed that the order commands are run in is random, due to the usage of a set() to store the commands in. Don't you think the order as they appear in a file would be nice to preserve?

[ewels]

I guess.. Or alphabetical? That would be easier (no need to track origin, which can be messy as it collapses identical commands so they could come from multiple files).

[ewels]

Ok, they're now sorted alphabetically and also show their origin. If the same command is called from multiple sources it'll just show the first one, whichever that happens to be.