[PATCH] kas: add colorlog to project dependencies

[Tue Duong]

The application natively supports colorized log output, but `colorlog`
is omitted from `pyproject.toml`. Consequently, installations via
Python package managers (like pip or pipx) lack colored logs by default,
degrading the debugging experience.

This omission is easily missed in development if the package is already
installed globally via system package managers (e.g., python3-colorlog
on Debian/Ubuntu).

Add `colorlog` to ensure consistent, colorized output across all standard
installations.

Signed-off-by: Tue Duong <tuedu...@gmail.com>
---
pyproject.toml | 1 +
1 file changed, 1 insertion(+)

diff --git a/pyproject.toml b/pyproject.toml
index d4ca1e7..6e6b181 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -50,6 +50,7 @@ classifiers = [
]
dynamic = [ "version" ]
dependencies = [
+ "colorlog >=6,<7",
"distro>=1,<2",
"gitpython>=3.1,<4",
"jsonschema>=3.2,<5",
--
2.55.0

[Jan Kiszka]

Thanks for bringing this up. But this is still an optional dependency
then. We should either model it like that

optional-dependencies.color = [
"colorlog>=6,<7"
]

or drop its optional state in the code as well. Given that it has always
been part of our container, I would not mind too much making it a must-have.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Tue Duong]

The application natively supports colorized log output, but `colorlog`

was omitted from `pyproject.toml`, making it an implicit optional
feature. This caused standard pip/pipx installations to lack colored
logs unless the package was already installed globally.

Since `colorlog` is already standard in the official containers, drop
its optional status and make it a core requirement. This ensures a
consistent debugging experience across all installations.

Signed-off-by: Tue Duong <tuedu...@gmail.com>
---

kas/kas.py | 9 ++-------
pyproject.toml | 1 +
2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/kas/kas.py b/kas/kas.py
index b87b404..c2b65a4 100644
--- a/kas/kas.py
+++ b/kas/kas.py
@@ -32,17 +32,12 @@ import asyncio
import distro
import traceback
import logging
+import colorlog
import signal
import sys
import os
from .kasusererror import KasUserError, CommandExecError

-try:
- import colorlog
- HAVE_COLORLOG = True
-except ImportError:
- HAVE_COLORLOG = False
-
from . import __version__, __file_version__, __compatible_file_version__
from . import plugins

@@ -60,7 +55,7 @@ def create_logger():
set_global_loglevel(DEFAULT_LOG_LEVEL.upper())
format_str = '%(asctime)s - %(levelname)-8s - %(message)s'
date_format = '%Y-%m-%d %H:%M:%S'
- if HAVE_COLORLOG and os.isatty(2):
+ if os.isatty(2):
cformat = '%(log_color)s' + format_str
colors = {'DEBUG': 'reset',
'INFO': 'reset',

diff --git a/pyproject.toml b/pyproject.toml
index d4ca1e7..6e6b181 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -50,6 +50,7 @@ classifiers = [
]
dynamic = [ "version" ]
dependencies = [
+ "colorlog >=6,<7",
"distro>=1,<2",
"gitpython>=3.1,<4",
"jsonschema>=3.2,<5",

--
2.55.0

[Jan Kiszka]

Thanks, looks better. However, [1] revealed that we need some global
control for coloring, with this even more. NO_COLOR seems like an
interesting, generic option. But as we already have --no-color for the
diff plugin, supporting that globally in addition would be good.

Jan

[1] https://groups.google.com/g/kas-devel/c/9u8s0lyWI50

[Tamino Larisch]

Hi, I can have a look at supporting a global no color option. Felix Moessbauer mentioned that issue to me today.

Best regards,

Tamino

[Nicholas Clark]

Would it make sense to also check whether stdout is a TTY? A lot of CLI tools use also isatty() to decide whether or not to colorize.

The logic could look like:

1. If NO_COLOR=1, disable colors. else:

2. if sys.stdout.isatty() and sys.stderr.isatty(), enable colors. else:

3. disable colors

[MOESSBAUER, Felix]

On Mon, 2026-07-13 at 09:32 -0400, Nicholas Clark wrote:
> Would it make sense to also check whether stdout is a TTY? A lot of CLI tools use also isatty() to decide whether or not to colorize.

Hi,

that definitely makes sense. We already have a couple of such checks in
kas, but it is not applied consistently.

[1] https://github.com/search?q=repo%3Asiemens%2Fkas%20isatty&type=code

>
> The logic could look like:
>
> 1. If NO_COLOR=1, disable colors. else:
> 2. if sys.stdout.isatty() and sys.stderr.isatty(), enable colors. else:
> 3. disable colors

Also that makes sense. We just need to ensure to forward the variable /
flag from kas-container into kas and make sure the tty detection is
correctly working on docker and podman.

Felix

> --
> You received this message because you are subscribed to the Google Groups "kas-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kas-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/kas-devel/CAKNeuBrNbJb09Qom-75dS%2BCCf1cGv3MCA-QPXHni9U-mpx3TSg%40mail.gmail.com.

[Thông Tuệ Dương]

Hi everyone,

Thanks for all your feedback!

Since the dependency fix in v2 is ready, I would welcome Jan to apply it as-is.

On the subject of supporting a global no-color option, I'm currently a bit busy with other tasks, so I would welcome Tamino to stack their new work on top of this. Since that feature relates directly to the discussion in this thread [1], it might be best to coordinate the implementation details over there.

[1] https://groups.google.com/g/kas-devel/c/9u8s0lyWI50

Vào lúc 21:16:06 UTC+7 ngày Thứ Hai, 13 tháng 7, 2026, MOESSBAUER, Felix đã viết:

[Jan Kiszka]

On 14.07.26 12:21, Thông Tuệ Dương wrote:
> Hi everyone,
>
> Thanks for all your feedback!
>
> Since the dependency fix in v2 is ready, I would welcome Jan to apply it
> as-is.
>
> On the subject of supporting a global no-color option, I'm currently a
> bit busy with other tasks, so I would welcome Tamino to stack their new
> work on top of this. Since that feature relates directly to the
> discussion in this thread [1], it might be best to coordinate the
> implementation details over there.
>
> [1] https://groups.google.com/g/kas-devel/c/9u8s0lyWI50

So far, people can opt-out from coloring by not providing that optional
dependency. With your patch, we would close even that option. Therefore,
I would like to address both things at the same time. Tamino could write
some patch(es) to add color control and then pick up your patch on top.
So it won't be lost, just delayed a bit more.

Jan