Spectre.Console (0.49.1) compatibility issue

[michaelplavnik]

This issue manifests as exception

2024-08-26 19:13:37.647 -04:00 [ERR] [ThreadId:10] ConsoleReport.print failed
System.Security.VerificationException: Method Spectre.Console.AlignableExtensions.Centered: type argument 'Spectre.Console.Rule' violates the constraint of type parameter 'T'.
   at NBomber.Infra.Console.addHeader(String header)
   at NBomber.DomainServices.Reports.ConsoleReport.ConsoleTestInfo.printTestInfo(TestInfo testInfo)
   at NBomber.DomainServices.Reports.ConsoleReport.print(ILogger logger, NodeSessionResult sessionResult, IDictionary`2 simulations)

My project is using Spectre.Console.Cli 0.49.1 and NBomber 5.7.0.

After brief analysis, it turns out that Spectre.Console has changed interface implemented by Rule class from IAlignable to IHasJustification as of version 0.46.

Most probably this issue in not on priority path, but might be it is time to migrate ?
Another consideration, is there a good reason to maintain Serilog.Sinks.SpectreConsole compared to default Serilog colored console?

[AntyaDev]

Hi @michaelplavnik
Thank you for this callout. We will check regarding upgrading NBomber to the latest SpectreConsole. We use SpectreConsole to render realtime tables. If you know some good alternative that provides such functionality we could consider it.

[michaelplavnik]

Thanks for including into 5.9!

I find Spectre.Console to be a good option for your project. May be instead, you can consider making immediate reporting to console a candidate for plugin design? More than one version of Spectre.Console can be supported then...

[AntyaDev]

May be instead, you can consider making immediate reporting to console a candidate for plugin design?

Can you please elaborate on this?

[michaelplavnik]

No magic here, design and code change for sure. Also plugin term stands for inverted dependency (multiple versions of the same assembly are not in scope).

NBomber product differentiator is its flexibility to build automated testing pipeline. If you agree, then interactivity is secondary concern and even harmful in its current form (I can attach screenshots from pipeline if interested).

In a very rough form, current functionality can be pushed into InteractiveConsoleSink and shipped as a separate package.
Next step is to completely eliminate dependency on Spectre.Console in core assembly. As core assembly depends on a low level primitives, higher level abstraction is required. But as far as I can see usage is limited.

[AntyaDev]

@michaelplavnik I understand your point. From what I have seen, nobody is usually interested in building such custom ConsoleSink adapters for their needs; instead, everybody wants to consume your library without additional setup manipulations. I guess people will ask you to update the dependency to the latest version versus building a custom ConsoleSink to solve some incompatibility.

Also, things we do with SpectreConsole will require considerable effort to be implemented properly in their CustomSink.