Silent yosys when using the python API

[KelvinChung2000]

As the title said, how do I silence yosys when using the Python API? I have tried:

import os
from contextlib import redirect_stderr, redirect_stdout

from pyosys import libyosys as ys

design = ys.Design()
ys.log_quiet_warnings = True
ys.run_pass("help read_verilog", design)

f = open(os.devnull, "w")
with redirect_stderr(f):
    with redirect_stdout(f):
        ys.run_pass("help read_verilog", design)

f.close()

And both of them do not work.

[KrystalDelusion]

Unfortunately there isn't much documentation on PYosys. -v and -q are available as command line options in Yosys for controlling log output, but it looks like they are read-only from inside Yosys. The tee command does let you call e.g. tee -q help read_verilog, which silences most of the output, except for the header:

>>> ys.run_pass("tee -q help read_verilog", design)

-- Running command `tee -q help read_verilog' --

There is also a log_to_stream function provided in the py_wrap_generator.py file, but I believe logs are output to all log_streams, not just the most recent, and the first thing the Yosys initializer does is Yosys::log_streams.push_back(&std::cout);.

[KelvinChung2000]

I think the variable is actually global (log_quiet_warnings) but it is not exposed by PYosys. But as you show the start of the initialisation is Yosys::log_streams.push_back(&std::cout); which means setting that will not matter.

[KrystalDelusion]

Yeah sorry, when I said read-only I meant they are only read

[KrystalDelusion]

This answer from stackoverflow seems to be relevant: https://stackoverflow.com/a/22434262

Basically the redirect_stdout context manager doesn't work on underlying os calls, but you can make an alternative redirector with os.dup2. With a quick local test, I get most of the output being redirected, which I suspect means that the buffer isn't being flushed properly, but there is a section which addresses how to solve this further down in the same answer.

[KelvinChung2000]

I will give this work around a go.

That Python C++ wrapper generator feels very fragile, inflexible, and difficult to maintain. It probably needs refactoring, but that seems like a lot of engineering.