Hi Jan, I have shared the initial draft patch [PATCH v1 0/2] installer: split backend APIs from frontend UI for your review. Thanks, Kasturi. On Monday, December 15, 2025 at 5:23:29 PM UTC+5:30 Jan Kiszka wrote: > On 15.12.25 10:58, Kasturi S wrote: > > Dear Isar Community, > > > > We are currently evaluating enhancements to the Isar installer and would > > like to share our plans, collect feedback, and align with upstream > > expectations before we proceed. > > > > During our work with the existing installer (deploy-image-wic.sh), we > > observed that both the backend logic and the frontend elements (dialogs, > > progress bars, UI prompts) are tightly coupled within a single script. > > This makes it difficult to extend the installer with new capabilities or > > integrate more advanced user-facing features. > > > > > > > > 1. Goals for Enhancing the Installer > > > > We would like to upgrade the installer across the following areas: > > > > •Advanced installation features > > > > Support for RAID creation from menu, etc. > > > > •Improved user experience > > > > The current shell-based UI is functional but limited. We would like to > > explore a more modern and user-friendly installer experience. > > > > > > > > 2. Proposed Refactoring > > > > To enable better extensibility, we propose to separate the frontend and > > backend: > > > > •Backend: > > > > Extract all installation logic into reusable shell-based API functions, > > allowing a clean and consistent interface. > > > > •Frontend: > > > > Move user interaction elements (dialogs, text UI, progress > > visualization) into separate files to avoid mixing UI with logic. > > > > This separation would keep the codebase more maintainable and make it > > easier to introduce new features or alternative frontends. > > > > > > > > 3. Optional Python-Based Frontend > > > > We are also considering offering an enhanced UI frontend using a Python- > > based framework. A Python UI would allow us to provide a richer, more > > intuitive interface that is difficult to achieve with pure shell > scripting. > > > > Our intention is: > > > > •If upstream is open to a Python-based UI, we would like to contribute > > this as an optional frontend. > > > > •If upstream prefers to keep the installer shell-based, we are happy to > > maintain the Python UI downstream while keeping the core backend APIs in > > upstream shell scripts. > > > > In this model, the backend APIs would remain shell-based and stable, > > while both shell and Python frontends would call into the same > > underlying API functions. This would ensure compatibility and avoid > > duplicating backend logic. > > > > Here is the basic example: > > > > Shell api: > > > > ``` > > > > sys_is_device_empty() { > > > > local -A ARGS > > > > local required=(device) > > > > api_args ARGS required[@] "$@" || { > > > > pack_return_data error "$_args_error" retval "1" > > > > return 1 > > > > } > > > > > > > > local fn="${FUNCNAME[0]}" > > > > local device="${ARGS[device]}" > > > > log_info "$fn" "Checking if device '$device' is empty" > > > > > > > > if cmp /dev/zero "$device" -n 1M >/dev/null 2>&1; then > > > > pack_return_data error "" retval "0" status "empty" > > > > else > > > > pack_return_data error "" retval "1" status "not_empty" > > > > fi > > > > } > > > > ``` > > > > Calling api from shell : > > > > ``` > > > > # Check if device is empty > > > > echo "Checking if device /dev/sdb is empty..." > > > > output=$(sys_is_device_empty device="/dev/sdb") > > > > echo "Output: $output" > > > > > echo > > > > ``` > > > > calling same api from python: > > > > ``` > > > > import subprocess > > > > def main(): > > > > # Check empty status > > > > result = is_device_empty(device="/dev/sdb") > > > > print("Result:", json.dumps(result, indent=2)) > > > > ``` > > > > 4. Request for Feedback > > > > Before we move ahead, we would appreciate feedback from the community on: > > > > 1.The idea of splitting the installer into modular backend and frontend > > components > > > > 2.Contributing backend installer logic as structured shell APIs > > > > This alone would definitely be welcome. It is a bit hard to find a good > abstraction when you only have one user in hands, but as you already > have a second one in mind (or already working?), it would be a great > chance to split backend and frontend. > > > 3.The possibility of supporting an optional Python-based UI frontend > > > > At least I would not mind having that second option in-tree as well. > Would both help to keep the abstraction working and may be useful for > other real use cases as well. > > > 4.Any concerns or suggestions regarding maintainability or integration > > > > We want to ensure that our work aligns with the long-term vision of the > > Isar project and benefits both upstream and downstream users. > > > > We look forward to the community’s thoughts and guidance on the best way > > to proceed. > > > > The original vision of pushing the installer to upstream was to have a > foundation for related work available, ideally in a form that more > complex, customized, branded etc. installer can build on top. In that > sense your ideas fit well. Make sure to present the code changes in > steps, likely similar as you described above, and the rest should just > be about details. > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center > -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/9e0e945e-a1ad-457f-a03a-7a291e3794c8n%40googlegroups.com.