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
