Following up on the second question, I've done some additional
experimentation and setup the warnings lib with appropriate
fatal_warnings and messenger which looks something like this:
https://github.com/apache/buildstream/commit/2464820b5fc11db34b51920bbb35929205ff2e41#diff-d7040f76f364bdd85649f70597d185b20ad7b995953f8d80ae61e71a1592cfb3R890-R891
On 2026-07-17 15:42, Nathan Williams via dev wrote:
Hi all,
I am looking to tackle:
https://github.com/apache/buildstream/issues/2028
So far I have located the relevant call-site where we can check for the
implicit list overwriting. I have added a placeholder implementation
using the warnings std lib while I wrote some appropriate test cases to
cover this new functionality.
https://github.com/apache/buildstream/commit/e41110ebf046181fcd30c2103f11f9a54a7deb51#diff-942232822a758f9330f027b9f3c5da5cb3b44e102afe5e20b37c8438a217286fR1423
But now I am struggling to replace the placeholder `warnings.warn`
function with the appropriate Loader._warn (or
Project._is_warning_fatal & Messenger.message) methods, that needs the
project context available at the call-site, to be able to use
Buildstreams custom warning (and messenger) system as this is deep
within the optimised node handling code.
1. What is the reason Buildstream uses a custom warning system over:
https://docs.python.org/3/library/warnings.html?
- At a guess this is because Buildstream pre-dates the warnings std
Python lib, or it's a performance optimisation, the commit messages
aren’t very clear, could someone shed some light?
2. Could we consider replacing the custom warnings implementation with
the standard warnings library?
- The warnings library could be tied into the custom messenger system
through setting the `warnings.showwarning` hook to a custom function
instead of the default function that outputs to stderr.
- Buildstream warning filtering could be done using python's standard
flexible filter format `action:message:category:module:line` instead of
custom buildstream one?
- not entirely sure how this would translate from the current
`<warning>` `<plugin>:<warning>` format
https://docs.buildstream.build/2.7/format_project.html#configurable-warnings
- It would make adding future warnings to obscure corners of the
codebase much easier, requiring only `import warnings`.
3. Any hints on how I could get the project context to the call-site in
node.pyx?
- I suspect we don't want to do this as it would introduce a lot of
nodes all referencing or passing around the loader/project context.
thanks,
Nathan
