Overall I think introducing Python to the build would provide net benefit, mainly from Kconfiglib, but could also find other good uses in e2e tests like Ricardo was working on. Most people's Linux distros ship with a Python interpreter too, so most developers would be unlikely to notice the extra dependency introduction.

In terms of Kconfiglib, we have a lot to gain by switching away from the Linux C implementation of Kconfig, mainly the ~30kloc of C code that we've forked from the Linux tree and hacked in our own customizations (KCONFIG_NEGATIVES). With Kconfiglib, these customizations get turned into a miniature Python script that we use to handle our custom header format, and a stable API to work off of so that we can uprev Kconfiglib without needing to change our scripts.

In terms of Kconfiglib's stability and track record: I think it has it covered. We adopted Kconfiglib in both Zephyr OS and in Depthcharge already without any issues at all.

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.

On Wed, Sep 29, 2021 at 5:39 AM Rao G <grao.v80@gmail.com> wrote:
Hi Patrick,

That's good to hear, would there be change to "make menuconfig" with kconfiglib 

No, we'd make it so that all the "make *config" commands run the Kconfiglib alternatives without any user action required.

The "menuconfig" interface in specific is very similar to the lxdialog-based interface that the C Kconfig uses, except it's a bit more polished and refined feeling.
 

Thanks
Ranga

On Wed, Sep 29, 2021 at 10:58 AM Patrick Georgi via coreboot <coreboot@coreboot.org> wrote:
Hi everybody,

Historically, coreboot avoided depending on python too much (we got rid of an entire python based configuration and build system, for example), with few minor exceptions.

The main reason has been that while python code is quick to slap together, it has demonstrated a penchant for breaking in all kinds of mysterious ways (python 2->3 really was just a slightly bigger instance of what's going on in python all the time), and its users demonstrate a disregard for their fellow developers as demonstrated by endless stack traces on trivial errors (or is the language too complicated to properly catch them all?)

While probably nice for one-off prototypes, long term maintenance is a concern: this project has over 20 years of history under its belt, with more to come.

That said, python makes its way back into the tree every now and then (typically as small snippets to compute and add hashes to binaries as needed by ARM SoCs). Uncanny, but typically not a big deal.

There are two bigger initiatives proposed that would significantly increase our python footprint:
1. Replacing Linux's kconfig with kconfiglib (https://review.coreboot.org/c/coreboot/+/48679)
2. Using pytest for end-to-end testing utilities (https://review.coreboot.org/c/coreboot/+/57869)

Compared to the "inject a hash value at a fixed location" scripts, these would probably be here to stay, and sufficiently integrated that everybody will have to deal with them.

People spending time working on python code when it has no chance to land isn't a good use of their time and we should avoid that in the project.

People spending time arguing that python shouldn't be used (to avoid the other outcome) even though the project's culture shifted and is now accepting Python isn't creating a great community for anybody.

To avoid these scenarios, could we possibly nail down the policy on python in coreboot?


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org


--

Jack Rosenthal (he/him/his)

Software Engineer - Chrome OS

Google Boulder

jrosenth@google.com

I value feedback from others. Please feel free to contact me directly, or file it anonymously at go/jrosenth-feedback.