public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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