From: Kasturi S <kasturishekar29@gmail.com>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: Refactoring and Optional Python Frontend for Isar Installer
Date: Sun, 18 Jan 2026 22:33:51 -0800 (PST) [thread overview]
Message-ID: <9e0e945e-a1ad-457f-a03a-7a291e3794c8n@googlegroups.com> (raw)
In-Reply-To: <0b7503b2-96d8-40e0-b9cb-d025c2f5abf3@siemens.com>
[-- Attachment #1.1: Type: text/plain, Size: 6316 bytes --]
Hi Jan,
I have shared the initial draft patch [PATCH v1 0/2] installer: split
backend APIs from frontend UI
<https://groups.google.com/g/isar-users/c/tbLPYeoCH4A> 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.
[-- Attachment #1.2: Type: text/html, Size: 8092 bytes --]
prev parent reply other threads:[~2026-01-19 6:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 9:58 Kasturi S
2025-12-15 11:53 ` 'Jan Kiszka' via isar-users
2026-01-19 6:33 ` Kasturi S [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e0e945e-a1ad-457f-a03a-7a291e3794c8n@googlegroups.com \
--to=kasturishekar29@gmail.com \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox