As a rule of thumb, any project involving a substantial amount of
Python always ends up needing a Docker container to build. So I'm in the
"no" camp for making Python a dependency, however I think it's fine to
keep things as-is where it can be used for helper scripts and utilities
for specific purposes such that they aren't critical to building the
tree.
I'm on the same side here. Building the documentation with python sphinx is a pain and I ended up needing docker.
The same can be said about edk2/tianocore which also uses a lot of python in critical parts of its build system.
At a minimum, I think we should consider introducing Python on an
optional basis (i.e., the C Kconfig implementation only gets used if a
Python interpreter is unavailable), but making it required would be even
better.
No. I don't like 'optional' things which do more or less the same as existing code. It's a great way to make the maintenance cost explode.
This is true in general (not just python tooling): adding alternative codepaths to do more or less the same as existing code creates a combinatorial explosion.
We have (had) 2 different bootblocks codepathds, multiple different cache as ram teardown mechanism, 2 resource different allocators, 2 MP init codepaths, 3 SMM init codepaths, ...
Tooling is not the place you want to add new optional codepaths (maybe toolchains can be an exception as different compilers catch different errors which improves code quality).
'Optional' things under the pretext to not break existing things looks like a nice idea at first sight, but it's a very bad strategy in the long run. I'd much rather stick to 1 thing, even
if it breaks the master branch, quickly fix things that broke and move on. I don't want to hijack the thread which is about python, but 'optional' python is worse than both no
python or mandatory python.