Enhance Rendering Functions by Adopting io.Reader and io.Writer for Rendering Functions Across cocli

[ravjot07]

Current Issue: Rendering functions have rigid input and output types, limiting their flexibility and reusability.
Proposed Solution: Modify rendering functions to accept io.Reader for input and io.Writer for output. This change will allow functions to handle various data sources and destinations seamlessly.

[ravjot07]

@deeglaze as pr your suggestions i have updated reading from an io.Reader and writing to an io.Writer.....

[thomas-fossati]

Current Issue: Rendering functions have rigid input and output types, limiting their flexibility and reusability.

While this is certainly true, it is unclear to me where we expect these to be reused outside the narrow context of the CLI.

[deeglaze]

I find myself calling the Golang libraries from Go rather than using subprocess with dup2 etc etc for using "cli" tools. Specifically having a corim pretty printer only through cocli is a little unfortunate.

[ravjot07]

Current Issue: Rendering functions have rigid input and output types, limiting their flexibility and reusability.

While this is certainly true, it is unclear to me where we expect these to be reused outside the narrow context of the CLI.

@thomas-fossati, I understand your concern regarding the narrow use within the CLI. The shift to io.Reader and io.Writer was aimed at improving flexibility and reusability, especially for scenarios like testing, web integrations, or tools where direct data handling is beneficial without relying on subprocess calls

[ravjot07]

I find myself calling the Golang libraries from Go rather than using subprocess with dup2 etc etc for using "cli" tools. Specifically having a corim pretty printer only through cocli is a little unfortunate.

@deeglaze, I agree that using Go libraries directly can simplify usage compared to subprocess approaches like dup2. The current refactor aims to make the rendering functions more adaptable while keeping the core functionality intact. Let me know if there's anything specific you'd like adjusted further.

[thomas-fossati]

I find myself calling the Golang libraries from Go rather than using subprocess with dup2 etc etc for using "cli" tools. Specifically having a corim pretty printer only through cocli is a little unfortunate.

It makes total sense, but wouldn't that be in the scope of veraison/corim rather than veraison/cocli?

[thomas-fossati]

Current Issue: Rendering functions have rigid input and output types, limiting their flexibility and reusability.

While this is certainly true, it is unclear to me where we expect these to be reused outside the narrow context of the CLI.

@thomas-fossati, I understand your concern regarding the narrow use within the CLI. The shift to io.Reader and io.Writer was aimed at improving flexibility and reusability, especially for scenarios like testing, web integrations, or tools where direct data handling is beneficial without relying on subprocess calls

All right, the "unit testing" use case looks like a compelling one.
Let's make use of the new functionality in the unit tests then :-)