Next features or improvements?

[xavierog]

As these lines are being written (2024-06-03), Moulti has reached version 1.10.0 and already brings more features than initially envisioned.

[huyz]

Man this project is great. I've been thinking about this for years too—like you, especially because I use Ansible.
Thanks for making this. I'll vote once I've used moulti for a bit

[MartyLake]

Great project, thanks for creating it!

[MartyLake]

Another direction moulti could take, is move to the ad-hoc IDE. For example, instead of receiving logs, moulti could receive steps to execute, and have buttons/shortcuts to

1. re-run
2. watch conditions to trigger the re-run

Example step I would find very useful: make configure build test

Another possibility, is to have a one-line terminal at the bottom of moulti, so one can type the next command to run, here that would be either make build or make test because I know I don’t need to configure everytime.

Another possibility, is to have this one-line terminal support readline, so that "re-run" is effectively " " when moulti is focused.

[xavierog]

As a first reflex, I would check existing tools.

Existing tools

Steps to execute

The first use case you describe reminds me of these tools:

• procmux
• mprocs
• mintaka -- able to focus on the first error
• mk -- focused on Makefiles

Have a look, maybe one of those is a closer match to your requirements? I am not sure they "watch conditions to trigger the re-run" though.

One-line terminal at the bottom

I had thought of it but did not jump to implementation for various reasons:

• there is a library to add terminals to Textual applications (thus providing all your usual comfort: your usual shell, aliases, functions, readline configuration, fzf and whatnot) but, if I remember correctly, it is not resize-friendly and that can be a problem

• at the end of the day, this is easily achieved using tmux (and possibly tmuxp):

  

  (possible alternatives: screen, zellij)

Back to Moulti

Of course, considering Moulti's design (an empty shell that just sits there until an external process fills it with contents), it remains possible to cover your use cases. I invite you to explore the tools above to get a better idea of your ideal setup. If Moulti remains the best candidate, then we can determine:

• what extra core feature would be required to implement your use case
• whether your use case should become a non-core feature (like ansible / diff / manpage), an example or a separate tool.

[huyz]

My first request for improvement is to be able to handle Ansible prompts. Right now I have some playbooks that just freeze up because they prompt the user for a password or to hit enter to continue.

[xavierog]

@huyz Moulti v1.13.0 handles Ansible vars_prompt.
The ergonomy is not perfect but I believe it is a good start.
Could you please give it a try and let me know whether it does the job?

[huyz]

@xavierog Sorry I was too busy to reply right away.

I wasn't thinking of vars_prompt actually. I don't use that feature (yet).

For me, I need prompts that are conditional (As I understand it, vars_prompt are too inflexible as they're hard to skip based on dynamic conditions.)

I was actually thinking of the pause's prompt feature: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/pause_module.html

Example:

- name: Prompt for ssh password if necessary
  when: ansible_password is undefined
  block:
    - name: PAUSE | Conditionally prompt for ssh password
      ansible.builtin.pause:
        prompt: "Password for {{ ansible_user | d('') }}@{{ ansible_host | d('unknown') }}"
        echo: false
      register: password_prompt
      no_log: true

    - name: SET_FACT | Set ansible_password
      ansible.builtin.set_fact:
        ansible_password: "{{ password_prompt.user_input }}"
      no_log: true

But huh, I just noticed that even with v1.11.0, I do get prompted for my passphrase when I run a command like ssh-add. I didn't know interactivity was already possible!

Let me go ahead and try v1.13.0 and see if your changes make any difference for my ansible.builtin.pause case.

You still want me to create an issue?

[huyz]

The problem I get is this:

ok: [mac] => {"ansible_facts": {"password_prompt": null}, "changed": false}                                                                                                                                                                                                  
    [WARNING]: Not waiting for response to prompt as stdin is not interactive   

[xavierog]

I was actually thinking of the pause's prompt feature:

Ok -- I was not aware of this Ansible module. Thanks for the real-life example, it helps.

I didn't know interactivity was already possible!

Moulti offers interactivity through inputquestion and buttonquestion widgets, available since v1.2.0 (2024-02-18).
Moulti also offers an askpass helper (moulti-askpass) with out of the box support for ssh and sudo since v1.7.0 (2024-04-28).
These features predate Ansible support, which appeared in v1.8.0 (2024-05-05) and benefits from them.

You still want me to create an issue?

That would be nice, especially to discuss possible implementation details.

The problem I get is this:

You get Not waiting for response to prompt as stdin is not interactive because the pause module leverages the Display.prompt_until method, which was left untouched by my work to support vars_prompt. I will investigate whether Moulti can support the pause module.

[huyz]

Filed #14

[xavierog]

To whoever voted Performance: improve behaviour when piping numerous lines to steps (e.g. using Python subinterpreters): Moulti 1.16.0 introduces significant performance improvements in that exact area. Roughly speaking, it is now possible to pipe 1 million lines to a given step with no user interface freeze and no excessive delay.
Therefore, could you please have a look at this version and report your experience here?