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, 15 Dec 2025 10:58:45 +0100 X-Sieve: CMU Sieve 2.4 Received: from mail-qt1-f187.google.com (mail-qt1-f187.google.com [209.85.160.187]) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 5BF9wh82017043 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Dec 2025 10:58:44 +0100 Received: by mail-qt1-f187.google.com with SMTP id d75a77b69052e-4f1d26abbd8sf69226921cf.1 for ; Mon, 15 Dec 2025 01:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765792718; x=1766397518; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Rgn+sIjc9vwFjsOAZ+13PzvjsUqNd2QXfsGHapwrINA=; b=i6Iz74UcNkK19cTg64vSzraovs66RTaFBuGRqOz7kqJgsAkRjxk/thRZxdsJLriide 0CB0/HUfbU8ipmmhowI+3LUdbMNeFy3bNbhYjijwfvsDYznMdROQmQTaPGpiubWBpc1f RhmVW7EXTVuXx3UrX3CV020nx07tpaCY9bnpCilHiOMVJy7O+GnwurahBudPlV3VYML8 VcApFEykVQ3VeE98QDGTw5ytPP0nLA21cki0wojmUEXXG7SsO1YmHKUaENutOCt8qW3X f9Y3ppohjlHfMZhgZ1H1yz8WMMJW7x6iDLFlNlf9BojwVieT7CcW7SedaOXNckFy02/s TQGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765792718; x=1766397518; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=Rgn+sIjc9vwFjsOAZ+13PzvjsUqNd2QXfsGHapwrINA=; b=JLq9Xb7HQ3dwlXDhUnaRcuKaOzljpqnKM7pSt6OhG1k+Ozq0ETfVkCLdgHwNoAQRXr 3OxKhnNPauR99mzZJiNbIbT6e0o0Kjy0RVEN2zUnZc5Ynqyo1mQk7HIW7YmSXzvuMmEl euVMKHwcGzR2cVyc6+Rj4nFMz10+8FTu3zfIIqBBSDuqqbU4sYsoe42S9l+T1EWfuWop VlidY097bPTg7jVOu+O97JLv6kft+6nuCHRwqeMyS8aC8LgD464QFmnC7NG3R4EMBA2m WUfAgvb26b8gyu1Dd5gGB/zTKgbDYf46ljEiq670gJF3JFTBuWjSCQdiePaQcU91IdOI JSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765792718; x=1766397518; 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:message-id:to:from:date :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=Rgn+sIjc9vwFjsOAZ+13PzvjsUqNd2QXfsGHapwrINA=; b=NJfGyPl3fWzq+R/6qpGsh+HCT91X6vkmnIGsM3fiYEGMwAysoQ3TKNDpVq0ToLGhSk cIx5sRB46nb3Uwvq1rYKB679icrQrVHI1mkG5hJhuKsGk/nD4jNriMxhvzXhC3HXj3FV BMDc9+YBzZxVwn/8NoN0VYK8KhjIvnXYfXSBE4kNOaDz5xGucdMkrlSbmuGHNfXcluUN QLTRCgnOrD/PRuWEJYVocTO8B+caB7ixtg0nMLfYpliZtlTiAaC0SzpqgaqRYdu6som5 KoaFccH29yc1iX5W4pO5BTSicEzv91NWWZiU4s+LxozvVNLUjMenCzxGZ7Fb8e09yaUr jqKg== Sender: isar-users@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVw+wH8NWXQnMTrbmCATigAHbGUZrlRGQl7Cm6hqXCKyiWv4B2VVhrE+BOg4lCzNlWkEAlf@ilbers.de X-Gm-Message-State: AOJu0YzZ4NDC3z3AjuX2FgMb95c4q9QM9Nm9UT3VRW4tGWv03Hbcchup PHCUTeuFzXH3y3WLfmOTvNSg19IKsWagwUPn3OQFga2ZEc3Pp/8ILVZJ X-Google-Smtp-Source: AGHT+IHxNcv/S5I4/wJYdof7HMmSf7cLYB1SLQ15AZPoFvXbVmUQ9pQJbgxiVm0tO5FMthT5y4xhVA== X-Received: by 2002:a05:622a:292:b0:4ee:4a3a:bd07 with SMTP id d75a77b69052e-4f1d061edfemr138486501cf.75.1765792717910; Mon, 15 Dec 2025 01:58:37 -0800 (PST) X-BeenThere: isar-users@googlegroups.com; h="AWVwgWbdTFZuJp+7nmjT6qsTFyRAy1sPCF/3r6Ca0UpuwVje3w==" Received: by 2002:a05:622a:1391:b0:4ee:1b36:aec4 with SMTP id d75a77b69052e-4f1ce9673ddls60284621cf.0.-pod-prod-08-us; Mon, 15 Dec 2025 01:58:37 -0800 (PST) X-Received: by 2002:a05:620a:344:b0:8a3:4887:227d with SMTP id af79cd13be357-8bb398dfed7mr1256927885a.5.1765792716823; Mon, 15 Dec 2025 01:58:36 -0800 (PST) Date: Mon, 15 Dec 2025 01:58:36 -0800 (PST) From: Kasturi S To: isar-users Message-Id: <58f37a12-3796-489d-be3f-f142ccf2d98dn@googlegroups.com> Subject: Refactoring and Optional Python Frontend for Isar Installer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_290238_1179011872.1765792716054" 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=-4.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,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: /MCp89Egwr8m ------=_Part_290238_1179011872.1765792716054 Content-Type: multipart/alternative; boundary="----=_Part_290239_1944807766.1765792716054" ------=_Part_290239_1944807766.1765792716054 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Isar Community, We are currently evaluating enhancements to the Isar installer and would=20 like to share our plans, collect feedback, and align with upstream=20 expectations before we proceed. During our work with the existing installer (deploy-image-wic.sh), we=20 observed that both the backend logic and the frontend elements (dialogs,=20 progress bars, UI prompts) are tightly coupled within a single script. This= =20 makes it difficult to extend the installer with new capabilities or=20 integrate more advanced user-facing features. =20 1. Goals for Enhancing the Installer We would like to upgrade the installer across the following areas: =E2=80=A2Advanced installation features Support for RAID creation from menu, etc. =E2=80=A2Improved user experience The current shell-based UI is functional but limited. We would like to=20 explore a more modern and user-friendly installer experience. =20 2. Proposed Refactoring To enable better extensibility, we propose to separate the frontend and=20 backend: =E2=80=A2Backend: Extract all installation logic into reusable shell-based API functions,=20 allowing a clean and consistent interface. =E2=80=A2Frontend: Move user interaction elements (dialogs, text UI, progress visualization)= =20 into separate files to avoid mixing UI with logic. This separation would keep the codebase more maintainable and make it=20 easier to introduce new features or alternative frontends. =20 3. Optional Python-Based Frontend We are also considering offering an enhanced UI frontend using a=20 Python-based framework. A Python UI would allow us to provide a richer,=20 more intuitive interface that is difficult to achieve with pure shell=20 scripting. Our intention is: =E2=80=A2If upstream is open to a Python-based UI, we would like to contrib= ute this=20 as an optional frontend. =E2=80=A2If upstream prefers to keep the installer shell-based, we are happ= y to=20 maintain the Python UI downstream while keeping the core backend APIs in=20 upstream shell scripts. In this model, the backend APIs would remain shell-based and stable, while= =20 both shell and Python frontends would call into the same underlying API=20 functions. This would ensure compatibility and avoid duplicating backend=20 logic. Here is the basic example: Shell api: ``` sys_is_device_empty() { local -A ARGS local required=3D(device) api_args ARGS required[@] "$@" || { pack_return_data error "$_args_error" retval "1" return 1 } =20 local fn=3D"${FUNCNAME[0]}" local device=3D"${ARGS[device]}" log_info "$fn" "Checking if device '$device' is empty" =20 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 : =20 ``` # Check if device is empty echo "Checking if device /dev/sdb is empty..." output=3D$(sys_is_device_empty device=3D"/dev/sdb") echo "Output: $output" echo = =20 ``` calling same api from python: ``` import subprocess def main(): =20 # Check empty status result =3D is_device_empty(device=3D"/dev/sdb") print("Result:", json.dumps(result, indent=3D2)) ``` 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=20 components 2.Contributing backend installer logic as structured shell APIs 3.The possibility of supporting an optional Python-based UI frontend 4.Any concerns or suggestions regarding maintainability or integration We want to ensure that our work aligns with the long-term vision of the=20 Isar project and benefits both upstream and downstream users. We look forward to the community=E2=80=99s thoughts and guidance on the bes= t way to=20 proceed. =20 Thanks, Kasturi. =20 --=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/= 58f37a12-3796-489d-be3f-f142ccf2d98dn%40googlegroups.com. ------=_Part_290239_1944807766.1765792716054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Isar Community,

We are currently evaluating enhancements to the Isar installer and would like to share our plans, collect feedback, and align wi= th 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 fron= tend 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.

=C2=A0

1. Goals for Enhancing the Installer

We would like to upgrade the installer across the following areas:

=E2=80=A2Advanced installation features

Support for RAID creation from menu, etc.

=E2=80=A2Improved user experience

The current shell-based UI is functional but limited. We would like to explore a more modern and user-friendly installer experience.=

=C2=A0

2. Proposed Refactoring

To enable better extensibility, we propose to separate the frontend and backend:

=E2=80=A2Backend:

Extract all installation logic into reusable shell-based API functions, allowing a clean and consistent interface.

=E2=80=A2Frontend:

Move user interaction elements (dialogs, text UI, progress visualization) into separate files to avoid mixing UI with logic.<= /p>

This separation would keep the codebase more maintainable and make it easier to introduce new features or alternative frontends.

=C2=A0

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 ric= her, more intuitive interface that is difficult to achieve with pure shell scripting.

Our intention is:

=E2=80=A2If upstream is open to a Python-based UI, we would like to contribute this as an optional frontend.

=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 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 duplica= ting backend logic.

Here is the basic example:

Shell api:

```

sys_is_device_empty() {

=C2=A0=C2=A0=C2=A0 local -A ARGS

=C2=A0=C2=A0=C2=A0 local required=3D(device)

=C2=A0=C2=A0=C2=A0 api_args ARGS required[@] "$@" || {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error "$_args_error" retval "1"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 1

=C2=A0=C2=A0=C2=A0 }

=C2=A0

=C2=A0=C2=A0=C2=A0 local fn=3D"${FUNCNAME[0]}"

=C2=A0=C2=A0=C2=A0 local device=3D"${ARGS[device]}"

=C2=A0=C2=A0=C2=A0 log_info "$fn" "Checking if device '$device' is empty"

=C2=A0

=C2=A0=C2=A0=C2=A0 if cmp /dev/zero "$device" -n 1M >/dev/null 2>&1; then

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error "" retval "0" status "empty"

=C2=A0=C2=A0=C2=A0 else

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pack_return_data error "" retval "1" status "not_empty"

=C2=A0=C2=A0=C2=A0 fi

}

```

Calling api from shell :=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

```

#=C2=A0 Check if device is empty

echo "Checking if device /dev/sdb is empty..."

output=3D$(sys_is_device_empty device=3D"/dev/sdb")

echo "Output: $output"

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

```

calling same api from python:

```

import subprocess

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

=C2=A0=C2=A0=C2=A0# Check empty status

=C2=A0=C2=A0=C2=A0 result =3D is_device_empty(device=3D"/dev/sdb")

=C2=A0=C2=A0=C2=A0 print("Result:", json.dumps(result, indent=3D2))

```

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

3.The possibility of supporting an optional Python-based UI frontend

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=E2=80=99s thoughts and guidance on the best way to proceed.

=C2=A0

Thanks,

Kasturi.

=C2=A0

--
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/58f37a12-3796-489d-be3f-f142ccf2d98dn%40googlegroups.com.
------=_Part_290239_1944807766.1765792716054-- ------=_Part_290238_1179011872.1765792716054--