Usability: Improve interactions with `Builder` instances

[GeigerJ2]

See also aiidateam/aiida-core#7003.

• print_builder function from aiida-wannier90-workflows (see here) (easier way to visualize structure of PB instance?)
• (not do for now) Auto-populating multiple, nested fields using one top-level constructor / method -> is being done for the options (pseudo_family option exists in aiida-wannier90-workflows)
• (long-term) define schemas for builders for each wf for validation?
• Other features that would allow simplifying interaction with the builder?
• custom_scheduler_commands, mpirun_extra_params, prepend_text

After discussion with @unkcpz, we should also contemplate what the ProcessBuilder level of abstraction adds on top of just importing the corresponding AiiDA class itself, and if it's worth it. Something to consider for a possible v3 (one could just define the different entities: process, inputs, outputs as dataclasses / via pydantic, but maybe I'm actually still missing something here...)

[unkcpz]

I'd like to see any documentation or design notes when the "builder" brought up first time (maybe somewhere in the team google drive Giovanni or @mbercx would know? ). It is hard to remove it because a lot of plugins rely on it. But in my opinion it is a typical example of over-engineering. If we have aiida-v3, it is something need to reconsidered.

What I want to see from aiida-core is a solid and "the only", and the most versatile interface to create and run the aiida process.

[mbercx]

Thanks for the ping @unkcpz, but even I do not have enough AiiDA seniority to predate the introduction of builders. ^^

I admittedly haven't put too much thought into alternatives, but I do appreciate the ability to get a populated builder from protocols and see the inputs you're going to run (also admittedly, I implemented that feature, so I'm biased ^^). I'm very keen to hear your thoughts @unkcpz, how would you simplify the process of providing inputs for more complex workflows?

[unkcpz]

I do appreciate the ability to get a populated builder from protocols and see the inputs you're going to run

see the catch here, I am not against from protocol to have something that can be further inspect and modified, but why that need to be the "builder"? and what is the "builder" means? Is it a builder pattern "builder" (I believe it is yes from the way it is used)? Then builder pattern builder discourage the modification after the build, so in aiida the builder was wrongly used.

how would you simplify the process of providing inputs for more complex workflows?

Just as what you do, and I think what you implemented "from_protocol" is a nice abstraction. But why not inputs_from_protocol? In the end, my hot take was: 1. builder was overkill, 2. builder pattern was wrongly used.

Maybe I missed some historical consideration, such as the design was a ad-hoc solution for certain project etc, so I'd appreciate anyone can provide some context to read through, otherwise as @GeigerJ2 mentioned, if there is a plan from aiida-v3, it is a thing need to be moved.

[GeigerJ2]

@unkcpz just for context, I traced back the introduction of the ProcessBuilder to #1116. Apart from that, all got already mentioned. Indeed, I'm also wondering why no inputs_from_protocol alternative constructor directly on the process was used 🤔

I opened aiidateam/aiida-core#7006 for further discussion, and to be able to add it to the AiiDA v3 GH project hehe