From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shymkent.ilbers.de ([unix socket]) by shymkent (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Mon, 19 Jan 2026 07:34:05 +0100 X-Sieve: CMU Sieve 2.4 Received: from mail-qv1-f60.google.com (mail-qv1-f60.google.com [209.85.219.60]) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 60J6Xx2Y024357 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 19 Jan 2026 07:34:04 +0100 Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-890805821c0sf151096216d6.3 for ; Sun, 18 Jan 2026 22:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1768804433; x=1769409233; darn=ilbers.de; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=Uvt3CS32clv4+eBiL4dJtPYvoAT7J3vpWS3ims2lOyQ=; b=G+O7Yh83V+03vtUX0SVBrPiQVbdo6XCqQfbPDPTMgKqlwmaYXtJCkpPDAez383ztSs MBYdybGu+HunpXJWC/aJlx8lmoBI43/3cDw5PHk0ljtGWsLRCAEiEd5kc8Oj6BAqJb+b I+jVAED3mVUQMPu/deJTXi2rPwtmg66eLalZxUm1T2fhgBbGkX5tbEF7RyE99NDbfmvT 4qaZJtOWKcds+2L49AkAWdFr20txzHxh/TPyIKq6j5JujGQEZtpguezmTNaGlddbMRAA OrYO3FJa4J7BvVcibQ6ZQL4qxJHubfmJLXaPYWmWttovCCqOMkgJ+SX6gdPhxjlv4JPg mAsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768804434; x=1769409234; darn=ilbers.de; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=Uvt3CS32clv4+eBiL4dJtPYvoAT7J3vpWS3ims2lOyQ=; b=m1npW4lQHnC2n3iQtzxgFA0ytqGSG544Tbidg35lGT3zGFLFmy+HjmhdEEhJgFUVfc rwwOf9dXg9RgEH+c6d2EqO28ZZVxKgjPmPS0McJt3J+zXL9U0gVcWtK6R2zGwE/93K2W NNwjOy/o401PWzN+zGpxiXsath/wrT7iHA5jNZRkx4fvnC57gtX36p6LeZc1c6FIMLdY sYKE6i4inYCLz2sFn4NSBFSmjEhi+4Ep9SI+gCpT85wOI/Ywpiovir7eLUd7T+1V3oKl vbdH50MwL0NJe9dfWNhLg5q96mejWRWo16lEBJL/fhcH0jlquowiAHbhoEYMK4sNVOpc OB3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768804434; x=1769409234; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :x-spam-checked-in-group:list-id:mailing-list:precedence :x-original-sender:mime-version:subject:references:in-reply-to :message-id:to:from:date:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=Uvt3CS32clv4+eBiL4dJtPYvoAT7J3vpWS3ims2lOyQ=; b=D//kTnEgC7Ol/ICSVZGaeQTgq3da9Oa59CK8nS3nbDE0m6AA57IUH1WQ53Xo0jeYI5 qNLnVYMVMndg+BgB/TYAWZRp4okCUr8G8vtPt/puFCZ3boN0PGuX1o5i6MtD65aVJOf/ X+PxXSam/wCT5/k4qTgJ/V187v/HHS+2zym8YIpkQcHU6LtJTLRogDMMg0Bsfo4gaq1X pSae9w9KUgRRb4JO5mctgqxUUTQVnc2I9M+ramTTB9VsZVZ4UYYOxJsKyudkYqusI+o4 1LQoccBmk6cgqu21/kShGml+oO9IJ1iJvzFUZz6dtGZUPqxxFqb22yjyLzfGubU8349t c17Q== Sender: isar-users@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWlCoDjeDJ27F+VlbVq+mO9jC1yZS8Z9348pv0148rOle/PZFOhuM/Y7/Dt9XbFnIYJo/GP@ilbers.de X-Gm-Message-State: AOJu0YztpDMqJKGAK+QVztabUCXavc/l/i+5u0jTBF6r2fgInHxLO1WS /J9+XIwxeil63UH6eXhzhbwsuRJwNrAL45CI36Gq5L7nNgc9fTSyFkUD X-Received: by 2002:a05:6214:27c6:b0:888:4930:82aa with SMTP id 6a1803df08f44-8942e54310fmr165120936d6.70.1768804433457; Sun, 18 Jan 2026 22:33:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com; h="AV1CL+E6x9sLJfoGONjKrYacGFgrfypNVK5/SC/HKg9AXlEgSQ==" Received: by 2002:a05:6214:1c09:b0:888:3be8:d4e8 with SMTP id 6a1803df08f44-894222e50b3ls45158476d6.2.-pod-prod-00-us; Sun, 18 Jan 2026 22:33:52 -0800 (PST) X-Received: by 2002:a05:6214:e4b:b0:88a:525a:8dbf with SMTP id 6a1803df08f44-893980c8ea5mr206847356d6.15.1768804432614; Sun, 18 Jan 2026 22:33:52 -0800 (PST) Date: Sun, 18 Jan 2026 22:33:51 -0800 (PST) From: Kasturi S To: isar-users Message-Id: <9e0e945e-a1ad-457f-a03a-7a291e3794c8n@googlegroups.com> In-Reply-To: <0b7503b2-96d8-40e0-b9cb-d025c2f5abf3@siemens.com> References: <58f37a12-3796-489d-be3f-f142ccf2d98dn@googlegroups.com> <0b7503b2-96d8-40e0-b9cb-d025c2f5abf3@siemens.com> Subject: Re: Refactoring and Optional Python Frontend for Isar Installer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_160802_343787300.1768804431613" X-Original-Sender: kasturishekar29@gmail.com Precedence: list Mailing-list: list isar-users@googlegroups.com; contact isar-users+owners@googlegroups.com List-ID: X-Spam-Checked-In-Group: isar-users@googlegroups.com X-Google-Group-Id: 914930254986 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Status: No, score=-3.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_MSPIKE_H2,RCVD_IN_RP_CERTIFIED,RCVD_IN_RP_RNBL,RCVD_IN_RP_SAFE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: wewfV/W2Pg/H ------=_Part_160802_343787300.1768804431613 Content-Type: multipart/alternative; boundary="----=_Part_160803_1201548263.1768804431613" ------=_Part_160803_1201548263.1768804431613 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan,=20 I have shared the initial draft patch [PATCH v1 0/2] installer: split=20 backend APIs from frontend UI=20 for your review. Thanks, Kasturi. On Monday, December 15, 2025 at 5:23:29=E2=80=AFPM UTC+5:30 Jan Kiszka wrot= e: > On 15.12.25 10:58, Kasturi S wrote: > > Dear Isar Community, > >=20 > > We are currently evaluating enhancements to the Isar installer and woul= d > > like to share our plans, collect feedback, and align with upstream > > expectations before we proceed. > >=20 > > 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 o= r > > integrate more advanced user-facing features. > >=20 > > =20 > >=20 > > 1. Goals for Enhancing the Installer > >=20 > > We would like to upgrade the installer across the following areas: > >=20 > > =E2=80=A2Advanced installation features > >=20 > > Support for RAID creation from menu, etc. > >=20 > > =E2=80=A2Improved user experience > >=20 > > The current shell-based UI is functional but limited. We would like to > > explore a more modern and user-friendly installer experience. > >=20 > > =20 > >=20 > > 2. Proposed Refactoring > >=20 > > To enable better extensibility, we propose to separate the frontend and > > backend: > >=20 > > =E2=80=A2Backend: > >=20 > > Extract all installation logic into reusable shell-based API functions, > > allowing a clean and consistent interface. > >=20 > > =E2=80=A2Frontend: > >=20 > > Move user interaction elements (dialogs, text UI, progress > > visualization) into separate files to avoid mixing UI with logic. > >=20 > > This separation would keep the codebase more maintainable and make it > > easier to introduce new features or alternative frontends. > >=20 > > =20 > >=20 > > 3. Optional Python-Based Frontend > >=20 > > 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=20 > scripting. > >=20 > > Our intention is: > >=20 > > =E2=80=A2If upstream is open to a Python-based UI, we would like to con= tribute > > this as an optional frontend. > >=20 > > =E2=80=A2If upstream prefers to keep the installer shell-based, we are = happy to > > maintain the Python UI downstream while keeping the core backend APIs i= n > > upstream shell scripts. > >=20 > > 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. > >=20 > > Here is the basic example: > >=20 > > Shell api: > >=20 > > ``` > >=20 > > sys_is_device_empty() { > >=20 > > local -A ARGS > >=20 > > local required=3D(device) > >=20 > > api_args ARGS required[@] "$@" || { > >=20 > > pack_return_data error "$_args_error" retval "1" > >=20 > > return 1 > >=20 > > } > >=20 > > =20 > >=20 > > local fn=3D"${FUNCNAME[0]}" > >=20 > > local device=3D"${ARGS[device]}" > >=20 > > log_info "$fn" "Checking if device '$device' is empty" > >=20 > > =20 > >=20 > > if cmp /dev/zero "$device" -n 1M >/dev/null 2>&1; then > >=20 > > pack_return_data error "" retval "0" status "empty" > >=20 > > else > >=20 > > pack_return_data error "" retval "1" status "not_empty" > >=20 > > fi > >=20 > > } > >=20 > > ``` > >=20 > > Calling api from shell : =20 > >=20 > > ``` > >=20 > > # Check if device is empty > >=20 > > echo "Checking if device /dev/sdb is empty..." > >=20 > > output=3D$(sys_is_device_empty device=3D"/dev/sdb") > >=20 > > echo "Output: $output" > >=20 > >=20 > echo = =20 > >=20 > > ``` > >=20 > > calling same api from python: > >=20 > > ``` > >=20 > > import subprocess > >=20 > > def main(): =20 > >=20 > > # Check empty status > >=20 > > result =3D is_device_empty(device=3D"/dev/sdb") > >=20 > > print("Result:", json.dumps(result, indent=3D2)) > >=20 > > ``` > >=20 > > 4. Request for Feedback > >=20 > > Before we move ahead, we would appreciate feedback from the community o= n: > >=20 > > 1.The idea of splitting the installer into modular backend and frontend > > components > >=20 > > 2.Contributing backend installer logic as structured shell APIs > >=20 > > 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 > >=20 > > 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 > >=20 > > We want to ensure that our work aligns with the long-term vision of the > > Isar project and benefits both upstream and downstream users. > >=20 > > We look forward to the community=E2=80=99s thoughts and guidance on the= best way > > to proceed. > >=20 > > 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 > > --=20 > Siemens AG, Foundational Technologies > Linux Expert Center > --=20 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 e= mail 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. ------=_Part_160803_1201548263.1768804431613 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan,=C2=A0

I have shared the initial draft patch=C2=A0[PATCH v1 0/2] in= staller: split backend APIs from frontend UI=C2=A0for your review.

Thanks,
Kasturi.

On Monday, December 15, 2025 at 5:23:29= =E2=80=AFPM UTC+5:30 Jan Kiszka wrote:
On 15.12.25 10:58, Kasturi S wrote:
> Dear Isar Community,
>=20
> 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.
>=20
> During our work with the existing installer (deploy-image-wic.sh),= we
> observed that both the backend logic and the frontend elements (di= alogs,
> progress bars, UI prompts) are tightly coupled within a single scr= ipt.
> This makes it difficult to extend the installer with new capabilit= ies or
> integrate more advanced user-facing features.
>=20
> =C2=A0
>=20
> 1. Goals for Enhancing the Installer
>=20
> We would like to upgrade the installer across the following areas:
>=20
> =E2=80=A2Advanced installation features
>=20
> Support for RAID creation from menu, etc.
>=20
> =E2=80=A2Improved user experience
>=20
> The current shell-based UI is functional but limited. We would lik= e to
> explore a more modern and user-friendly installer experience.
>=20
> =C2=A0
>=20
> 2. Proposed Refactoring
>=20
> To enable better extensibility, we propose to separate the fronten= d and
> backend:
>=20
> =E2=80=A2Backend:
>=20
> Extract all installation logic into reusable shell-based API funct= ions,
> allowing a clean and consistent interface.
>=20
> =E2=80=A2Frontend:
>=20
> Move user interaction elements (dialogs, text UI, progress
> visualization) into separate files to avoid mixing UI with logic.
>=20
> This separation would keep the codebase more maintainable and make= it
> easier to introduce new features or alternative frontends.
>=20
> =C2=A0
>=20
> 3. Optional Python-Based Frontend
>=20
> We are also considering offering an enhanced UI frontend using a P= ython-
> based framework. A Python UI would allow us to provide a richer, m= ore
> intuitive interface that is difficult to achieve with pure shell s= cripting.
>=20
> Our intention is:
>=20
> =E2=80=A2If upstream is open to a Python-based UI, we would like t= o contribute
> this as an optional frontend.
>=20
> =E2=80=A2If upstream prefers to keep the installer shell-based, we= are happy to
> maintain the Python UI downstream while keeping the core backend A= PIs in
> upstream shell scripts.
>=20
> In this model, the backend APIs would remain shell-based and stabl= e,
> while both shell and Python frontends would call into the same
> underlying API functions. This would ensure compatibility and avoi= d
> duplicating backend logic.
>=20
> Here is the basic example:
>=20
> Shell api:
>=20
> ```
>=20
> sys_is_device_empty() {
>=20
> =C2=A0=C2=A0=C2=A0 local -A ARGS
>=20
> =C2=A0=C2=A0=C2=A0 local required=3D(device)
>=20
> =C2=A0=C2=A0=C2=A0 api_args ARGS required[@] "$@" || {
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error = "$_args_error" retval "1"
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1
>=20
> =C2=A0=C2=A0=C2=A0 }
>=20
> =C2=A0
>=20
> =C2=A0=C2=A0=C2=A0 local fn=3D"${FUNCNAME[0]}"
>=20
> =C2=A0=C2=A0=C2=A0 local device=3D"${ARGS[device]}"
>=20
> =C2=A0=C2=A0=C2=A0 log_info "$fn" "Checking if devi= ce '$device' is empty"
>=20
> =C2=A0
>=20
> =C2=A0=C2=A0=C2=A0 if cmp /dev/zero "$device" -n 1M >= /dev/null 2>&1; then
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error = "" retval "0" status "empty"
>=20
> =C2=A0=C2=A0=C2=A0 else
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error = "" retval "1" status "not_empty"
>=20
> =C2=A0=C2=A0=C2=A0 fi
>=20
> }
>=20
> ```
>=20
> Calling api from shell :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>=20
> ```
>=20
> #=C2=A0 Check if device is empty
>=20
> echo "Checking if device /dev/sdb is empty..."
>=20
> output=3D$(sys_is_device_empty device=3D"/dev/sdb")
>=20
> echo "Output: $output"
>=20
> echo=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>=20
> ```
>=20
> calling same api from python:
>=20
> ```
>=20
> import subprocess
>=20
> def main():=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>=20
> =C2=A0=C2=A0=C2=A0# Check empty status
>=20
> =C2=A0=C2=A0=C2=A0 result =3D is_device_empty(device=3D"/dev/= sdb")
>=20
> =C2=A0=C2=A0=C2=A0 print("Result:", json.dumps(result, i= ndent=3D2))
>=20
> ```
>=20
> 4. Request for Feedback
>=20
> Before we move ahead, we would appreciate feedback from the commun= ity on:
>=20
> 1.The idea of splitting the installer into modular backend and fro= ntend
> components
>=20
> 2.Contributing backend installer logic as structured shell APIs
>=20

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 fronte= nd
>=20

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 integra= tion
>=20
> We want to ensure that our work aligns with the long-term vision o= f the
> Isar project and benefits both upstream and downstream users.
>=20
> We look forward to the community=E2=80=99s thoughts and guidance o= n the best way
> to proceed.
>=20

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

--=20
Siemens AG, Foundational Technologies
Linux Expert Center

--
You received this message because you are subscribed to the Google Groups &= quot;isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to isar-use= rs+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-use= rs/9e0e945e-a1ad-457f-a03a-7a291e3794c8n%40googlegroups.com.
------=_Part_160803_1201548263.1768804431613-- ------=_Part_160802_343787300.1768804431613--