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.
On Thu, Sep 30, 2021 at 7:01 AM David Hendricks david.hendricks@gmail.com wrote:
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.
On Wed, Sep 29, 2021 at 2:58 AM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote:
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.
...
To avoid these scenarios, could we possibly nail down the policy on python in coreboot?
The policy should be simple: The CI system (Jenkins) must be able to build every target in its default configuration.
If we introduce Python as a dependency, then all Python in the tree must be compatible with whatever version Jenkins uses. And if we're going to impose the burden of fixing Python on everyone, then all developers must have the ability to install a compatible version in their OS. Given the experiences many of us in this thread have had and how widely distros vary in Python support, I don't see this as tenable.
Another thing to keep in mind is that we have these sorts of helper scripts from multiple vendors/parties over several years, and we'll likely see more in the future. Pushing them all to use whatever version(s) of Python we decide to build with does not seem realistic.
All that said, I'm fine with Python being used for helper scripts and such as we've done in the past. It gives developers/vendors/etc. freedom to use whatever works for their purposes without imposing a huge burden on everyone else. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org