Backend info logged to stdout rather than stderr

[BrunoLiegiBastonLiegi]

While working on the qibo cloud side, we noticed that the info about which backend is being used ends up in the stderr. I wonder if it would be a problem to move it to the stdout instead. Basically by defining a custom StreamHandler in qibo.config if I am not mistaken. What do you think @stavros11 @alecandido, do I have the green light for this?

[alecandido]

To be fair, I'd be in favor of stripping the logging completely. It is rather unexpected for a library to log (you would be surprised to see it happening from NumPy).

In any case, if you want to do this, I have no special preference. But, may I ask you why?

[BrunoLiegiBastonLiegi]

It originated from the fact that on the cloud webapp the info about the backend is reported in the stderr tab:

because the database stores separately the stderr and stdout from the execution. @scarrazza thus suggested that this would be weird for an end user, and that it would make more sense to have it in the stdout tab.

We could try and operate some regex to surgically extract the line from the stderr and place it in the stdout, but it is probably not the most reliable approach...

[scarrazza]

To simplify we could also concatenate both logs a single entry.

[alecandido]

We could try and operate some regex to surgically extract the line from the stderr and place it in the stdout, but it is probably not the most reliable approach...

No, not worth it.

To simplify we could also concatenate both logs a single entry.

That's an option.

But, to be fair, the execution backend is a relevant enough information that I would add it in the "Summary" table.

You can extract it just querying .get_backend(), if the execution is done using a global backend (set with set_backend()), or otherwise extracting it from the AbstractBackend-subclass instance.
Even though, since you're instantiating it in the first place, this information should already be available in the runner, and it can be communicated to the cloud through the same channel as the rest of the info (or a similar one).

(I'm not advocating to not apply the proposed change anyhow, that's perfectly fine by me - in this sense, you certainly have my green light)

[stavros11]

What do you think @stavros11 @alecandido, do I have the green light for this?

From my side, moving from stderr to stdout or even concatenating both logs are both acceptable solutions, so feel free to go ahead. The backend message does not make sense to be logged as an error anyway.

Other than that, I would agree with @alecandido about removing the logging and for that particular application getting the backend using some other function and printing it as part of the summary.